The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Первый стабильный релиз СУБД Drizzle

16.03.2011 16:34

После двух лет альфа и бета тестирования анонсирован первый стабильный релиз СУБД Drizzle, готовый для повседневного использования. Проект Drizzle был основан в июле 2008 года с целью создания упрощенного и более быстрого варианта MySQL, в котором убрана поддержка утяжеляющих работу MySQL возможностей, которые планируется реализовать в виде плагинов. БД позиционируется как высоконадежная и поддерживающая ACID-транзакции. В качестве хранилища используется InnoDB и PBXT. Исходные тексты проекта переписаны на языке C++ и распространяются в рамках лицензии GPLv2. Инициатором проекта является Брайан Эйкер (Brian Aker), бывший директор MySQL AB по архитектуре, но управление разработкой Drizzle целиком находится в руках независимого сообщества.

По сравнению с MySQL в Drizzle удалена поддержка хранимых процедур (вместо CREATE FUNCTION следует использовать связываемые объекты), триггеров, кэша запросов (query cache), представлений (view), операции GRANT и ALTER, ограничений ACL, команды SHOW, предварительно подготовленных запросов (prepared statement). Прекращена поддержка следующих типов данных: SET, TIME, YEAR, TINYINT/SMALLIN/MEDIUMINT, TINYBLOB/MEDIUMBLOB/LONGBLOB, TINYTEXT/MEDIUMTEXT/LONGTEXT, UNSIGNED, GEOMETRY, POINT, LINESTRING, POLYGON, FULLTEXT. Из поддерживаемых типов данных отмечаются: INTEGER, BIGINT, DOUBLE/FLOAT, DECIMAL/NUMERIC, VARCHAR, BLOB, TEXT, DATE, TIMESTAMP, DATETIME, ENUM.

В отличие от SQLite, СУБД Drizzle не претендует на роль встраиваемого решения и реализована в виде сервера. Архитектура Drizzle построена на основе идеи микро-ядра и подключаемых через модули дополнительных возможностей. В СУБД основной упор делается на оптимизацию для работы в Cloud-инфраструктуре и для обеспечения работы web-приложений (максимальное упрощение структуры БД и вынос логики на сторону приложений). В частности, дизайн СУБД позволяет организовать обработку большого числа параллельных запросов, при выполнении которых в полной мере задействуются мощности многоядерных CPU. Имеются встроенные средства для разнесения данных по ключевому полю (шардинг) на кластер из нескольких машин.

Большое внимание также уделяется процессу упрощения выполнения типовых задач по использованию и администрированию СУБД. Возможности репликации в Drizzle обеспечиваются через передачу лога транзакций, поддержка работы в slave-режиме реализована в виде отдельного плагина. Функции по упрощению миграции с MySQL поддерживаются в штатной утилите drizzledump. Для выполнения административных функций подготовлена утилита drizzleadmin. В отличие от MySQL, код клиентской библиотеки libdrizzle распространяется в рамках лицензии BSD.

  1. Главная ссылка к новости (http://blog.drizzle.org/2011/0...)
  2. OpenNews: Представлена новая открытая СУБД VoltDB
  3. OpenNews: Представлена новая БД Hibari, созданная для больших хранилищ данных
  4. OpenNews: Релиз открытой БД HyperSQL 2.0
  5. OpenNews: Доступен стабильный релиз СУБД MariaDB 5.2
  6. OpenNews: Релиз HailDB 2.2.0, встраиваемой БД на основе InnoDB
Лицензия: CC-BY
Тип: Программы
Короткая ссылка: https://opennet.ru/29937-Drizzle
Ключевые слова: Drizzle, MySQL, database
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (38) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Anonus (?), 17:04, 16/03/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Это все очень хорошо! Но как же MySQL?
     
     
  • 2.2, klalafuda (?), 17:26, 16/03/2011 [^] [^^] [^^^] [ответить]  
  • +8 +/
    > Это все очень хорошо! Но как же MySQL?

    А что MySQL? Работает себе и работает. Все ОК с MySQL.

     
  • 2.6, rshadow (?), 18:49, 16/03/2011 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Есть Drizzle и есть MariaDB. Забудьте про название MySQL.
     
     
  • 3.16, onono (?), 06:40, 17/03/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    марийодб уже стало интерпрайз решением?
     
     
  • 4.18, anonymous (??), 08:07, 17/03/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > марийодб уже стало интерпрайз решением?

    мускуль когда-то был «интерпрайз решением»? O_O

     
     
  • 5.24, klalafuda (?), 11:51, 17/03/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > мускуль когда-то был «интерпрайз решением»? O_O

    Под мускулем крутятся далеко не только странички Васи Пупкина.

     
  • 3.19, klalafuda (?), 08:11, 17/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Есть Drizzle и есть MariaDB.

    Что-то я не вижу указанных приложений ни в репозитории RHEL & K ни в Debian-е. Они вообще существуют в живой природе? Или пока что сугубо в лаборатории?

     
     
  • 4.25, Аноним (-), 12:12, 17/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Может в RHEL их и не добавили, а вот в gentoo они существуют. drizzle в официальном репозитории, mariadb в оверлее mysql

    *  dev-db/drizzle [ Masked ]
          Latest version available: 7.2011.03.11
          Latest version installed: [ Not Installed ]
          Size of files: 10,519 kB
          Homepage:      http://drizzle.org
          Description:   Database optimized for Cloud and Net applications
          License:       GPL-2

    *  dev-db/mariadb
          Latest version available: 5.1.53
          Latest version installed: 5.1.53
          Size of files: 24,080 kB
          Homepage:      http://askmonty.org/
          Description:   MariaDB is a MySQL fork with 3rd-party patches and additional storage engines merged.
          License:       GPL-2

     
  • 4.26, Aqueelone (?), 12:41, 17/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Как раз в Дебиане они есть:

    #aptitude search drizzle
    p   libdrizzle-dbg                                                         - library for the Drizzle and MySQL protocols, debug symbols                      
    p   libdrizzle-dev                                                         - library for the Drizzle and MySQL protocols, development files                  
    p   libdrizzle-doc                                                         - library for the Drizzle and MySQL protocols, API documentation                  
    p   libdrizzle0                                                            - library for the Drizzle and MySQL protocols                                    
    p   python-drizzle                                                         - Python binding to libdrizzle                                                    
    p   python-drizzle-dbg                                                     - Python binding to libdrizzle - debug symbols                                    
    p   python3-drizzle                                                        - Python3 binding to libdrizzle                                                  
    p   python3-drizzle-dbg                                                    - Python3 binding to libdrizzle - debug symbols  

    # aptitude show libdrizzle0
    Пакунок: libdrizzle0                        
    Стан: встановлений
    Версія: 0.8-1
    Пріоритет: Додаткові (Extra)
    Розділ: libs
    Супроводжуючий: Monty Taylor <mordred@inaugust.com>
    Розмір в розпакованому стані: 131 k
    Залежить: libc6 (>= 2.1.3)
    Опис: library for the Drizzle and MySQL protocols
    libdrizzle is library implementing the Drizzle and MySQL protocols. It has been designed to be light on memory usage, thread safe, and provide full access
    to server side methods.

    This package the Drizzle client library.
    Домівка: http://launchpad.net/libdrizzle

     
     
  • 5.32, klalafuda (?), 13:21, 17/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Как раз в Дебиане они есть:

    Да, в дебе оказывается есть. Искал по mariadb не нашел.

     
  • 5.41, Денис Юсупов (?), 14:43, 20/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Офф, но украинский язык как обычно, взорвал мозг. "Пакунок", хм.
     

  • 1.3, Igor S. Kovalenko (?), 17:32, 16/03/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А это и есть тот мускуль, который так нужен (по преимуществу сайтостроителям, но и не только)

    Потому что дальше начинается пародия на нежно любимый pgsql, и вот она то, - пародия, - не нужна никак.

     
     
  • 2.9, klalafuda (?), 23:43, 16/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > А это и есть тот мускуль, который так нужен (по преимуществу сайтостроителям, но и не только)

    MySQL без ALTER? Ну-ну. Удачи в бою и инкрементальном апдейте схемы базы..

     
     
  • 3.14, Sylvia (ok), 03:25, 17/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    тут скорее не "удалена", а "пока не реализована"
    если будет сильный спрос на это, то поддержка может быть реализована,
    тем более что практически весь функционал реализован через плагины.


     
     
  • 4.23, Остров (?), 08:55, 17/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    И далее "если будет сильный спрос на это, то поддержка может быть реализована" по всем пунктам хотелок пользователей ))
     
  • 2.10, klalafuda (?), 23:45, 16/03/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > А это и есть тот мускуль, который так нужен (по преимуществу сайтостроителям, но и не только)

    Да, и отказ от prepared statements - это сильно. SQL Injection следит за тобой. Пристально. Особенно в контексте веб-сайта.

     
     
  • 3.12, Аноним (-), 00:25, 17/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >Да, и отказ от prepared statements - это сильно. SQL Injection следит за тобой. Пристально. Особенно в контексте веб-сайта.

    В нормальных веб-фреймворках вроде Django или Rails об этом заботиться не надо. На сегодняшний день SQL Injection это проблема прежде всего для индусов PHP-шников.

     
     
  • 4.13, angra (ok), 02:31, 17/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Вы пытаетесь сказать что Django или Rails настолько тупые, что не могут использовать prepared statement API конкретного SQL сервера? Или что они магически добавили поддержку Drizzle задолго до его релиза? Или что под PHP нет фреймворков с ORM?
    И кстати индусы от ORM замечательно порождают каскады SQL запросов там, где индусы от чистого PHP делают всего один запрос с join.
     
     
  • 5.15, бедный буратино (ok), 04:37, 17/03/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > И кстати индусы от ORM замечательно порождают каскады SQL запросов там, где индусы от чистого PHP делают всего один запрос с join.

    Где-то я это уже слышал. C vs Assembler. Портабельный компактный код vs "зато дешевле".

     
  • 5.20, klalafuda (?), 08:16, 17/03/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > И кстати индусы от ORM замечательно порождают каскады SQL запросов там, где индусы от чистого PHP делают всего один запрос с join.

    Тот же Yii (его ORM) прекрасно генерирует JOIN запросы. Хотя вроде не должно. Он же на пыхыпы.. А ить поди ж ты.

     
  • 5.28, Aqueelone (?), 12:56, 17/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Вы пытаетесь сказать что Django или Rails настолько тупые, что не могут
    > использовать prepared statement API конкретного SQL сервера? Или что они магически
    > добавили поддержку Drizzle задолго до его релиза?

    Drizzle сделан таким образом, что для любого программера "пять секунд" сделать "поддрежку Drizzle" для Rails, Django и Symfony "тупо" клонировав "поддержку Mysql".
    Собственно, то, что не вошло (не поддержуется) Drizzle -- как раз в большинстве своём не поддержуется (не используется) нормальными фреймворками.

     
  • 4.21, klalafuda (?), 08:20, 17/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > В нормальных веб-фреймворках вроде Django или Rails об этом заботиться не надо.
    > На сегодняшний день SQL Injection это проблема прежде всего для индусов
    > PHP-шников.

    ORM и SQL Injection - это как бы ортогональные друг другу вещи. Наличие первого отнюдь не исключает наличие второго. В первую очередь все зависит от того, как и через какое место ORM общается с API конкретной базы. Это даже без учета того, что зачастую ORMы позволяют выполнение прямых SQL запросов для 'особых случаев'. И как правило такие случаи нет нет да найдутся.

     
     
  • 5.29, Aqueelone (?), 13:01, 17/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> В нормальных веб-фреймворках вроде Django или Rails об этом заботиться не надо.
    >> На сегодняшний день SQL Injection это проблема прежде всего для индусов
    >> PHP-шников.
    > ORM и SQL Injection - это как бы ортогональные друг другу вещи.
    > Наличие первого отнюдь не исключает наличие второго. В первую очередь все
    > зависит от того, как и через какое место ORM общается с
    > API конкретной базы. Это даже без учета того, что зачастую ORMы
    > позволяют выполнение прямых SQL запросов для 'особых случаев'. И как правило
    > такие случаи нет нет да найдутся.

    Вообще-то, сама идеология MVC подразумевает НЕ ВОЗМОЖНОСТЬ SQL Injection -- так как ВСЯ РАБОТА С БД должна происходить на уровне модели.
    Конечно, Вы в состоянии ручками "машрутизировать" запрос таким образом, что SQL Injection будет возможен, но тут нужно весьма постараться, чего явно не хватает для тех, в чью голову может прийти сия не простая идея! И, в любом случае, это будет нарушение самой концепции MVC.

     
     
  • 6.34, klalafuda (?), 13:54, 17/03/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Вообще-то, сама идеология MVC подразумевает НЕ ВОЗМОЖНОСТЬ SQL Injection -- так как
    > ВСЯ РАБОТА С БД должна происходить на уровне модели.
    > Конечно, Вы в состоянии ручками "машрутизировать" запрос таким образом, что SQL Injection
    > будет возможен, но тут нужно весьма постараться, чего явно не хватает
    > для тех, в чью голову может прийти сия не простая идея!
    > И, в любом случае, это будет нарушение самой концепции MVC.

    Идеология - да, возможно. Но на практике мне может понадобиться построить хитрожопую выборку, которую модель в конкретном фреймворке может и не покрыть. Или же сделать это жутко неоптимально. Идеология идеологией, но работать тоже нужно.

    Опять же, повторюсь, ORM (модель в MVC) и SQL Injection - это все-таки не зависящие друг от друга вещи. Вот есть у меня модель UserProfile и есть текстовое поле userName. Очень грубо говоря:

    $x = new UserProfile;
    $x->userName = $_POST['userName'];
    $x->save();

    Какой SQL запрос будет выполнен в конечном итоге? Как он будет выглядеть? Будет ли использоваться для передачи userName prepared statement или же будут предприняты попытки экранирования пользовательского ввода? Естественно, что как таковой паттерн MVC или ORM не дает ответа на эти вопросы. Все это уже зависит от конкретной реализации. И никто не мешает в конкретном фреймворке накосячить так, что через конечный SQL запрос я смогу исполнить свой подставляемый извне SQL код. Хотя внешне с точки зрения приложения все вроде бы как бы и через модель и пр.

     
     
  • 7.35, Остров (?), 16:42, 17/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> Опять же, повторюсь, ORM (модель в MVC) и SQL Injection - это все-таки не зависящие друг от друга вещи.

    Стоит заметить, что любой вебовский MVC не есть MVC в силу того, что контроллер не исполняет возложенных на него этой моделью функций. Когда говорят про MVC модель для вебприложений, то сильно лукавят.

     
     
  • 8.40, klalafuda (?), 00:05, 18/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Тут скорее вопрос - что первично модель или контроллер Ну или даже нет Мод... текст свёрнут, показать
     
  • 7.38, Аноним (-), 23:34, 17/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >Идеология - да, возможно. Но на практике мне может понадобиться построить хитрожопую выборку, которую модель в конкретном фреймворке может и не покрыть.

    Элементарно, ватсон. Устанавливаете соответсвующий пакет питона/руби и будет у вас возможность из фреймворка задействовать хоть prepared statements, хоть PL/SQL или PL/pgSQL.

     
     
  • 8.39, klalafuda (?), 23:57, 17/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Это если низлежащий RDBMS поддерживает соотв ф-ть Ну а если нет - селяви ... текст свёрнут, показать
     
  • 4.27, Aqueelone (?), 12:50, 17/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >>Да, и отказ от prepared statements - это сильно. SQL Injection следит за тобой. Пристально. Особенно в контексте веб-сайта.
    > В нормальных веб-фреймворках вроде Django или Rails об этом заботиться не надо.
    > На сегодняшний день SQL Injection это проблема прежде всего для индусов
    > PHP-шников.

    В нормальнных PHP-CMF, например Symfony2.0, аналогично.
    Если добавить, например, связку Symfony-NetBeans -- то получается вообще интересно.
    В чем тут суть... есть вэб-сервер, есть sql-сервер, но для работы с IDE не плохо иметь "лайт" версию базы данных для экспериментов, причем эта "лайт-версия" желательна максимально приближенной по структуре с "продакш"-версией.
    Вот именно для этих целей Drizzle -- оптимальный вариант, даже если "продакш"-версия -- что-то на уровне PG/SQL.

     
     
  • 5.33, klalafuda (?), 13:44, 17/03/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > В чем тут суть... есть вэб-сервер, есть sql-сервер, но для работы с IDE не плохо иметь "лайт" версию базы данных для экспериментов, причем эта "лайт-версия" желательна максимально приближенной по структуре с "продакш"-версией. Вот именно для этих целей Drizzle -- оптимальный вариант, даже если "продакш"-версия -- что-то на уровне PG/SQL.

    Ээээ... А обычный MySQL или PgSQL то чем не устраивают в качестве лайт-версии :-? Вроде легче и проще ещё поискать нужно. Мы ж не про ораклу сейчас прости господи не к ночи будет сказано обсуждаем..

     

  • 1.4, terr0rist (ok), 18:02, 16/03/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Идея хорошая. Но название не могли получше придумать? название в современном мире - половина успеха.
     
     
  • 2.7, Sylvia (ok), 19:19, 16/03/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Дождь,

    неблагозвучность названия на русском разработчиков не волнует вероятно, они возможно даже и не знают )

     
     
  • 3.30, Aqueelone (?), 13:04, 17/03/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Дождь,
    > неблагозвучность названия на русском разработчиков не волнует вероятно, они возможно даже
    > и не знают )

    Никто (BSD-лицензия!) не мешает сделать форк с благозвучным (багозвучным) названием.

     
  • 2.8, Аноним (-), 20:01, 16/03/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Правильный спросить "язык не могли получше придумать".
     

  • 1.11, Аноним (-), 23:52, 16/03/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Какое ж, блин, название неприятное.
     
  • 1.17, anonymous (??), 08:07, 17/03/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >По сравнению с MySQL в Drizzle удалена поддержка…

    слушайте, а что осталось-то? мультиклиентность ещё удалят пусть — и попробуют сказать, чем оно лучше SQLite.

     
     
  • 2.22, klalafuda (?), 08:23, 17/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > слушайте, а что осталось-то? мультиклиентность ещё удалят пусть — и попробуют сказать, чем оно лучше SQLite.

    Если сравнивать со скулайтом то, как минимум, вменяемая работа с базой в многопоточном приложении, прозрачный сетевой доступ к базе и пр. Боюсь, чтобы сравнивать кастрированного MySQL со скулайтом от него нужно отрезать слишком много.

     
     
  • 3.36, anonymous (??), 17:32, 17/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    ты это… читать умеешь, а? не, я помню, что не умеешь, вопрос риторический. я и сказал, что если это отрезать (или с SQLite привинтить, что я, например, делал) — оно даже SQLite проиграет. зато на C++.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2022 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру