Директор MySQL по архитектуре Брайан Эйкер (Brian Aker) представил (http://krow.livejournal.com/602409.html) проект Drizzle (https://launchpad.net/drizzle), в рамках которого создается упрощенный и более быстрый вариант MySQL, в котором будет убрана (http://drizzle.wikia.com/wiki/MySQL_Differences) поддержка некоторых типов данных, хранимых процедур, триггеров, кэша запросов (query cache), представлений (view), операции GRANT и системы ACL, команды SHOW, предварительно подготовленных запросов (prepared statement) и других утяжеляющих работу MySQL возможностей. В качестве хранилища по умолчанию будет использован InnoDB.Развитие проекта будет полностью делегировано комьюнити, по схеме подобной взаимодействию Fedora и RedHat. В качестве лицензии выбрана GPL v2.
Архитектура Drizzle построена на основе идеи микро-ядра и подключаемых в виде модулей дополнительных возможностей.
URL: http://www.builderau.com.au/news/soa/Drizzle-MySQL-slims-dow...,339028227,339290807,00.htm
Новость: http://www.opennet.ru/opennews/art.shtml?num=17090
Бесполезный проект. Даже не могу представить что те, которых MySQL устраивает, по-чему то захотят его "облегчать".
Нас (scribd.com) - устроит, facebook и fotolog (сегодня спрашивал у них) - тоже устроит :-)
>Нас (scribd.com) - устроит, facebook и fotolog (сегодня спрашивал у них) -
>тоже устроит :-)Ради чего? На чём экономим?
>Ради чего? На чём экономим?Если уж нужна легкая БД без крутых фич - тут по-моему выигрышно смотрится sqlite который юзают все кому не лень.Он вообще не клиент-сервер и вся библа - 300 кил кода.Вместе движком бд и поддержкой довольно большого набора SQL, база одним файлом.Итого самое оно для применений где фич обычного MySQL слишком много, IMHO.
>>Ради чего? На чём экономим?
> Если уж нужна легкая БД без крутых фич - тут по-моему выигрышно
> смотрится sqlite который юзают все кому не лень.Он вообще не клиент-сервер
> и вся библа - 300 кил кода.Вместе движком бд и поддержкой
> довольно большого набора SQL, база одним файлом.Итого самое оно для применений
> где фич обычного MySQL слишком много, IMHO.Для ОДИНОЧНОГО пользователя\процесса - да.
Для МАЛЮСЕНЬКОГО сайта с МИЗЕРНОЙ посещаемостью - да.SQLite неспособна параллельно обрабатывать даже средне нагруженные сайты.
Проверь сам что будет, если ты будешь одновременно читать из SQLite и писать. Тестани эдак на 10 читателях и 3 писателях хотя бы. Если не глуп, то поймешь, что SQLite - недоСУБД. Правда, ты очень удивишься, что и разработчики SQLite это не скрывают.
Кстати, оффтоп, но поздравляю с новой, кажется интересной, работой.
Как первый шаг, перевод на nginx вижу уже произошел :)
Чем открывать файлы .scb?
А те - кого он не устраивает?
Например, я реально не понимаю - за каким на сравнительно простых запросах и небольшом числе пользователей он там много жрет ресурсов
Хм, возвращение к 3.x?
> Хм, возвращение к 3.x?С чего бы это?
Развитый язык SQL - остается.
Но останется под присмотром Sun?
innocat + innogrep? :)
Ха-ха. Нет, это просто смешно. Когда MySQL был 3.23, многие выбирали его из-за высокой скорости отдачи запросов, простоты установки, отсутствия триггеров, хранимых процедур. Сегодня MySQL оброс множеством функций, что делает его непригодным в ряде проектов, и поэтому создается облегченная версия MySQL - Drizzle.Вопрос - сколько пройдет времени, прежде чем появится облегченная версия Drizzle?
> Ха-ха. Нет, это просто смешно. Когда MySQL был 3.23, многие выбирали его
> из-за высокой скорости отдачи запросов, простоты установки, отсутствия триггеров, хранимых
> процедур. Сегодня MySQL оброс множеством функций, что делает его непригодным в
> ряде проектов, и поэтому создается облегченная версия MySQL - Drizzle.
> Вопрос - сколько пройдет времени, прежде чем появится облегченная версия Drizzle?Как выяснилось - первый официально стабильный релиз спустя 2 года
может стоило покурить sqlite чем шашкой махать сгоряча
Тригеры в нем есть :) Не подходит :)
>Тригеры в нем есть :) Не подходит :)<cut>в котором будет убрана поддержка некоторых типов данных, хранимых процедур, триггеров </cut> :] ^^^^^^^^^^^ ^^^^^^^^
>>Тригеры в нем есть :) Не подходит :)
> <cut>в котором будет убрана поддержка некоторых типов данных, хранимых процедур, триггеров
> </cut> :] ^^^^^^^^^^^
>
>
>
>
> ^^^^^^^^В SQLite тригеры есть.
Чтобы что-то убрать, нужно сначала это по-человечески реализовать. И была безобразно кастрированная СУБД, а теперь вообще от СУБД останется одно название.
> Чтобы что-то убрать, нужно сначала это по-человечески реализовать. И была безобразно кастрированная
> СУБД, а теперь вообще от СУБД останется одно название.С чего бы это?
dBASE куда как проще, а тем не менее - самая настоящая СУБД.Вы специфику СУБД для веба не понимаете. Для большинства хостеров ну вовсе не нужен оверхед ресурсов, а подавляющему числу движков сайтов - ну вовсе не нужны те возможности, что создают этот оверхед.
>Чтобы что-то убрать, нужно сначала это по-человечески реализовать. И была >безобразно кастрированная СУБД, а теперь вообще от СУБД останется одно название.идите в сад любезный - есть масса программ которым мускул нужен в режиме записная книжка. Это проги типа DC хабов - всевозможные небольшие самописные служебные программы и т.д.
есть масса задача для которых не нужна полноценная СУБД
Так в таких программах действительно sqlite место
> Так в таких программах действительно sqlite местоНе-а.
Такие записные книжки, блоги и т.п. бывают иногда ну очень посещаемы.
>>Чтобы что-то убрать, нужно сначала это по-человечески реализовать. И была >безобразно кастрированная СУБД, а теперь вообще от СУБД останется одно название.
>
>идите в сад любезный - есть масса программ которым мускул нужен в
>режиме записная книжка. Это проги типа DC хабов - всевозможные небольшие
>самописные служебные программы и т.д.
>
>есть масса задача для которых не нужна полноценная СУБДТогда чем sqlite не устраивает?
>Тогда чем sqlite не устраивает?У sqlite 4 большие проблемы:
1. Решения на его основе не масштабируются
2. Он совершенно не тянет нагрузку, т.е. по одному запросу выполняет нормально, а при необходимости обработки параллельных запросов не годится.
3. у него нет средств кеширования данных, он каждый раз лезет на диск.
4. Это не СУБД, а библиотека.
Drizzle идеален для web-приложений, для которых производительность критична, а все перечисленное в новости совершенно не нужно. Создатели MySQL наконец особнали, что постоянное усложнение до добра не доведет, кося в сторону enterprise, они теряют главную нишу - web.
> Drizzle идеален для web-приложений, для которых производительность критичнаБез query cache? Бгыгы.
В жизни не тратил памяти на query cache.
Под высокой нагрузкой он приносит только ущерб.
Вы бы попробовали, прежде чем такие утверждения делать.1. На кластере используйте репликацию, синхронную или асинхронную. На одном хосте в отличии от других баз при увеличении числа ядер производительность растет _линейно_.
2. Нагрузку держит существенно лучше даже постгреса, не говоря про мускуль. Постгрес на железе типа пентиум Д с саташным винтом держит порядка 150-200 средней сложности транзакций в секунду, эскулайт минимум на порядок больше.
3. Вы про кэширование чтения или записи? Если про чтение, есть shared cache, который следует включить для этой цели. Если про кэширование записи - после завершения транзакции данные принудительно сбрасываются на диск, хотя это можно отключить директивами PRAGMA.
4. Библиотека тоже может быть СУБД. Только эта СУБД из класса встраиваемых.
> Нагрузку держит существенно лучше даже постгреса, не говоря про мускуль.Прошу прощения, но мускуль пока ещё был всё же легче постгреса
И ещё раз прошу прощения, а что у нас с конкурентными запросами в sqlite?
http://www.sqlite.org/faq.html
http://www.sqlite.org/features.html
Думаю найдете ответы на все свои вопросы.
>Думаю найдете ответы на все свои вопросы.Мы наверное с разных планет. Не нашёл ни одного положительного ответа. Подскажите, что я делаю не так?
>> Нагрузку держит существенно лучше даже постгреса, не говоря про мускуль.
>
>Прошу прощения, но мускуль пока ещё был всё же легче постгресаМускуль легче, проще, хуже держит нагрузку и медленнее на комплексных запросах. Последнее зависит не от "легкости", а от планировщика. Тема не раз обсуждалась, найти результаты тестирования проблем не составит. Хотя замечу, что если у вас выборки без объединения таблиц, мускуль быстрее. При объединении нескольких таблиц быстрее постгрес. Зато мускуль админить проще, репликация есть, очень много пользователей и легко найти информацию.
>И ещё раз прошу прощения, а что у нас с конкурентными запросами
>в sqlite?Запросы на чтение могут выполняться одновременно, на запись - последовательно. Если вы хотите создать очередь запросов, используйте функцию sqlite3_busy_timeout. Замечу, что на саташных винтах очередь запросов на запись работает много эффективнее, чем куча конкурентных запросов к диску. Учитывая, что одна транзакция занимает от 500 микросекунд, можно выполнять сотни запросов на запись плюс тысячи на чтение в секунду. Учитывая возможность эскулайта присоединять к открытой базе другие базы (по умолчанию 10 баз, а лимит на 32-бит машине 30 баз), можно партишионировать базу (например, отдельная база на каждый филиал компании) и получать производительность еще выше, сохраняя возможность строить отчеты по данным из всех баз совместно.
Если у вас нагрузка более сотен запросов на запись в секунду, можно создавать базу в ОЗУ. Например, хранение сессионной информации выгодно делать именно так, а при запуске/останове сервера приложений копировать базу с диска/на диск.
>Вы бы попробовали, прежде чем такие утверждения делать.Я как-то пытался поднять RT на sqlite, рассудив, что для такой задачи MySQL будет как из пушки по воробьям. К тому времени как в базе накопилось около 1000 тикетов, что само по себе смехотворная цифра, размер базы был около 2 Мб, каждая операция занимала по несколько секунд. После того как заменили sqlite на MySQL, все стало летать, нагрузка на сервер упала до нуля. Вторая попытка была с поднятием какого-то web-форума (название из головы вылетело) с базой на sqlite, все повторилось точь в точь, вначале все гладко, но как только увеличивается объем данных и начинают появляться параллельные запросы - тормозит по страшному.
>[оверквотинг удален]
>Я как-то пытался поднять RT на sqlite, рассудив, что для такой задачи
>MySQL будет как из пушки по воробьям. К тому времени как
>в базе накопилось около 1000 тикетов, что само по себе смехотворная
>цифра, размер базы был около 2 Мб, каждая операция занимала по
>несколько секунд. После того как заменили sqlite на MySQL, все стало
>летать, нагрузка на сервер упала до нуля. Вторая попытка была с
>поднятием какого-то web-форума (название из головы вылетело) с базой на
>sqlite, все повторилось точь в точь, вначале все гладко, но как
>только увеличивается объем данных и начинают появляться параллельные запросы - тормозит
>по страшному.Даже не знаю, что вам сказать... чтоб не обидеть :-) По личному опыту - базы эскулайт до 100 гиг работают очень быстро. Большие базы не проверял, будет под рукой свободный винт на терабайт, проверю.
>Даже не знаю, что вам сказать... чтоб не обидеть :-) По личному
>опыту - базы эскулайт до 100 гиг работают очень быстро. Большие
>базы не проверял, будет под рукой свободный винт на терабайт, проверю.Вполне может быть, что описанные мной проблемы SQLite наблюдаются только во FreeBSD или являются ошибкой в определенной версии, я использовал SQLite 3.2.x.
>>Даже не знаю, что вам сказать... чтоб не обидеть :-) По личному
>>опыту - базы эскулайт до 100 гиг работают очень быстро. Большие
>>базы не проверял, будет под рукой свободный винт на терабайт, проверю.
>
>Вполне может быть, что описанные мной проблемы SQLite наблюдаются только во FreeBSD
>или являются ошибкой в определенной версии, я использовал SQLite 3.2.x.В указанной вами версии блокировка конкурентного доступа на внутреннем мьютексе работала очень плохо, следовало использовать блокировку на уровне вызывающего приложения (сервера приложений).
А вообще это было лет эдак пять назад, вы бы сравнивали и с мускулем версии 3.х.
Сейчас в эскулайте аналог PostGIS есть с индексом b-tree, полнотекстовый поиск (и не как в постгресе, где скорость его работы такая, что в вебе применить нереально) и еще много возможностей enterprize уровня. Плюс возможность репликации базы с сервера на мобильные устройства и обратно, репликации в память и т.п.
>[оверквотинг удален]
>плохо, следовало использовать блокировку на уровне вызывающего приложения (сервера приложений).
>
>А вообще это было лет эдак пять назад, вы бы сравнивали и
>с мускулем версии 3.х.
>
>Сейчас в эскулайте аналог PostGIS есть с индексом b-tree, полнотекстовый поиск (и
>не как в постгресе, где скорость его работы такая, что в
>вебе применить нереально) и еще много возможностей enterprize уровня. Плюс возможность
>репликации базы с сервера на мобильные устройства и обратно, репликации в
>память и т.п.Veter, ну не знаю даже что сказать. Лайт этот тормоз невероятный на всех операционках. Не надо народ вводить в заблуждение! Мы тестировали его и на Windows, и на OS X и на линуксах. Картина везде абсолютно одинаковая. Был бы лайт коммерческия - я б сказал что ты засланный казачок :)
Полнотекстный поиск в лайте реализован топорно, почитайте их Вики. Просто добавили таблицы вспомагательные и шмалят туда инфу.
Вас послушать мистер Ветер, так в 300 Кб кода Лайт решили все те задачи что занимают десятки метров во взрослых базах, причем на порядок быстрее. Ну ты сам подумай о чем говориш да? Тогда Ораклу, Саю, МС СКЛ и прочем ловить просто нечего сегодня! Так по твоей логике? :-)
> Даже не знаю, что вам сказать... чтоб не обидеть :-)бакула на sqlite при нескольких лямах записей в базе и объёме в 5Гб никак не работала, тока винтом шуршала. Пришлось от sqlite отказаться. Да, кстати, а есть у sqlite аналог repair или ещё чего-нить чтобы целостность восстановить?
>Вы бы попробовали, прежде чем такие утверждения делать.
>
>1. На кластере используйте репликацию, синхронную или асинхронную. На одном хосте в
>отличии от других баз при увеличении числа ядер производительность растет _линейно_.ну пробовали. Я не понимаю чего такую пургу гнать?
Лайт ваще однопоточный внутри - о чем ты тут рассказываеш?!
Посмотри исходники или хотя бы доку почитай ламер>2. Нагрузку держит существенно лучше даже постгреса, не говоря про мускуль. Постгрес
>на железе типа пентиум Д с саташным винтом держит порядка 150-200
>средней сложности транзакций в секунду, эскулайт минимум на порядок больше.да расскажи! :-) Может быть на тех ихних примерах в 1000 записей?
Ваще пародия у них на сайте.Лайт загибается уже если в базе есть несколько тыс записей.
Может ты просто гонял тупой запрос на одной таблице типа WHERE fld = X
а ты попробуй прогнать что нибудь типа джойна на 5-10 таблицах или агрегацию на джойнах.
Лайт в принципе не имеет блокировок записей! Так что как он тебе отработает паралельно что то ?Если кто то хочет увидеть настоящую скорость пацаны, попробуйте Valentina базочку.
Она жарит mySQL/MS SQL/Oracle в 50-100 (!!!) раз. Сам не верил пока не проверил!
Смотри здесь http://www.valentina-db.comПричем что в ней классно, она может работать и как встраиваемая - то есть бьет лайт, и как нормальный сервер с клиентами из под разных языков. Кстати похоже что делают ее наши хлопцы.
>>Тогда чем sqlite не устраивает?
> У sqlite 4 большие проблемы:
> 1. Решения на его основе не масштабируются
> 2. Он совершенно не тянет нагрузку, т.е. по одному запросу выполняет нормально,
> а при необходимости обработки параллельных запросов не годится.
> 3. у него нет средств кеширования данных, он каждый раз лезет на
> диск.
> 4. Это не СУБД, а библиотека.4. Попрошу не оскорблять. Есть весьма сурьезные библиотеки-СУБД. То же FireBird
От мне какраз такая легкая "записная книжка" очень нужна, так что я "за" такой проект
>От мне какраз такая легкая "записная книжка" очень нужна, так что я
>"за" такой проектсделай эту записную книжку на LDAP
>>От мне какраз такая легкая "записная книжка" очень нужна, так что я
>>"за" такой проект
> сделай эту записную книжку на LDAPlivejournal.com ?
>От мне какраз такая легкая "записная книжка" очень нужна, так что я
>"за" такой проектКури sqlite
>>От мне какраз такая легкая "записная книжка" очень нужна, так что я
>>"за" такой проект
> Кури sqliteЙа-йа, натурлих. Особенно на реальном посещаемом веб-сайте.
Пионерия, что с вас взять...
Все понимаю, можно облегчить, согласен.
Но Query cache то можно было оставить, иначе получится полное пэ
> Все понимаю, можно облегчить, согласен.
> Но Query cache то можно было оставить, иначе получится полное пэОни же как решение для облаков толкают.
А query cache памяти ой как немало кушает.
форк?
>и других утяжеляющих работу MySQL возможностей.И нахрена оно такое нужно когда sqlite его на данном поле по легковесности натянет как тузик грелку?
>>и других утяжеляющих работу MySQL возможностей.
> И нахрена оно такое нужно когда sqlite его на данном поле по
> легковесности натянет как тузик грелку?Я Вам больше скажу - есть еще FoxPro...
Очень быстрый.
На ОДНОМ пользователе.
Может они еще исключат SQL из MySQL чтобы не утяжелял работу ? :)
>Может они еще исключат SQL из MySQL чтобы не утяжелял работу ?
>:)Кстате, офигенно правильная мысль.
>>Может они еще исключат SQL из MySQL чтобы не утяжелял работу ?
>>:)
> Кстате, офигенно правильная мысль.Уже реализовано:
Плуг-ин HandlerSocket для MySQL
http://l-o-n-g.livejournal.com/153756.html
> Может они еще исключат SQL из MySQL чтобы не утяжелял работу ?
> :)Этим другие проекты занимаются.
А для Drizzle - полноценный SQL принципиально должен быть.