URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 43010
[ Назад ]

Исходное сообщение
"OpenNews: В рамках проекта Drizzle начата разработка легковесного варианта MySQL"

Отправлено opennews , 24-Июл-08 00:51 
Директор 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.me/opennews/art.shtml?num=17090


Содержание

Сообщения в этом обсуждении
"В рамках проекта Drizzle начата разработка легковесного варианта MySQL"
Отправлено Oles , 24-Июл-08 00:51 
Бесполезный проект. Даже не могу представить что те, которых MySQL устраивает, по-чему то захотят его "облегчать".

"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено Аноним , 24-Июл-08 01:02 
Нас (scribd.com) - устроит, facebook и fotolog (сегодня спрашивал у них) - тоже устроит :-)

"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено Oles , 24-Июл-08 01:43 
>Нас (scribd.com) - устроит, facebook и fotolog (сегодня спрашивал у них) -
>тоже устроит :-)

Ради чего? На чём экономим?


"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено User294 , 26-Июл-08 19:04 
>Ради чего? На чём экономим?

Если уж нужна легкая БД без крутых фич - тут по-моему выигрышно смотрится sqlite который юзают все кому не лень.Он вообще не клиент-сервер и вся библа - 300 кил кода.Вместе движком бд и поддержкой довольно большого набора SQL, база одним файлом.Итого самое оно для применений где фич обычного MySQL слишком много, IMHO.


"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено Гыгыка , 02-Фев-11 17:32 
>>Ради чего? На чём экономим?
> Если уж нужна легкая БД без крутых фич - тут по-моему выигрышно
> смотрится sqlite который юзают все кому не лень.Он вообще не клиент-сервер
> и вся библа - 300 кил кода.Вместе движком бд и поддержкой
> довольно большого набора SQL, база одним файлом.Итого самое оно для применений
> где фич обычного MySQL слишком много, IMHO.

Для ОДИНОЧНОГО пользователя\процесса - да.
Для МАЛЮСЕНЬКОГО сайта с МИЗЕРНОЙ посещаемостью - да.

SQLite неспособна параллельно обрабатывать даже средне нагруженные сайты.
Проверь сам что будет, если ты будешь одновременно читать из SQLite и писать. Тестани эдак на 10 читателях и 3 писателях хотя бы. Если не глуп, то поймешь, что SQLite - недоСУБД. Правда, ты очень удивишься, что и разработчики SQLite это не скрывают.


"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено Alrond , 24-Июл-08 03:49 
Кстати, оффтоп, но поздравляю с новой, кажется интересной, работой.
Как первый шаг, перевод на nginx вижу уже произошел :)

"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено tty01 , 24-Июл-08 07:52 
Чем открывать файлы .scb?

"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено Гыгыка , 02-Фев-11 17:29 
А те - кого он не устраивает?
Например, я реально не понимаю - за каким на сравнительно простых запросах и небольшом числе пользователей он там много жрет ресурсов

"В рамках проекта Drizzle начата разработка легковесного варианта MySQL"
Отправлено Gambler , 24-Июл-08 00:56 
Хм, возвращение к 3.x?

"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено Гыгыка , 02-Фев-11 17:29 
> Хм, возвращение к 3.x?

С чего бы это?
Развитый язык SQL - остается.


"В рамках проекта Drizzle начата разработка легковесного варианта MySQL"
Отправлено pavlinux , 24-Июл-08 01:23 
Но останется под присмотром Sun?

"В рамках проекта Drizzle начата разработка легковесного варианта MySQL"
Отправлено Jerzy , 24-Июл-08 06:09 
innocat + innogrep? :)

"В рамках проекта Drizzle начата разработка легковесного варианта MySQL"
Отправлено tty01 , 24-Июл-08 07:03 
Ха-ха. Нет, это просто смешно. Когда MySQL был 3.23, многие выбирали его из-за высокой скорости отдачи запросов, простоты установки, отсутствия триггеров, хранимых процедур. Сегодня MySQL оброс множеством функций, что делает его непригодным в ряде проектов, и поэтому создается облегченная версия MySQL - Drizzle.

Вопрос - сколько пройдет времени, прежде чем появится облегченная версия Drizzle?


"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено Гыгыка , 02-Фев-11 17:34 
> Ха-ха. Нет, это просто смешно. Когда MySQL был 3.23, многие выбирали его
> из-за высокой скорости отдачи запросов, простоты установки, отсутствия триггеров, хранимых
> процедур. Сегодня MySQL оброс множеством функций, что делает его непригодным в
> ряде проектов, и поэтому создается облегченная версия MySQL - Drizzle.
> Вопрос - сколько пройдет времени, прежде чем появится облегченная версия Drizzle?

Как выяснилось - первый официально стабильный релиз спустя 2 года


"В рамках проекта Drizzle начата разработка легковесного варианта MySQL"
Отправлено idkfa , 24-Июл-08 07:27 
может стоило покурить sqlite чем шашкой махать сгоряча

"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено Аноним , 24-Июл-08 09:49 
Тригеры в нем есть :) Не подходит :)

"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено Cosgor , 24-Июл-08 10:05 
>Тригеры в нем есть :) Не подходит :)

<cut>в котором будет убрана поддержка некоторых типов данных, хранимых процедур, триггеров </cut> :]       ^^^^^^^^^^^                                                 ^^^^^^^^


"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено Гыгыка , 02-Фев-11 17:35 
>>Тригеры в нем есть :) Не подходит :)
> <cut>в котором будет убрана поддержка некоторых типов данных, хранимых процедур, триггеров
> </cut> :]       ^^^^^^^^^^^  
>            
>            
>            
>            
>   ^^^^^^^^

В SQLite тригеры есть.


"В рамках проекта Drizzle начата разработка легковесного варианта MySQL"
Отправлено Все тот же аноним , 24-Июл-08 08:59 
Чтобы что-то убрать, нужно сначала это по-человечески реализовать. И была безобразно кастрированная СУБД, а теперь вообще от СУБД останется одно название.

"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено Гыгыка , 02-Фев-11 17:38 
> Чтобы что-то убрать, нужно сначала это по-человечески реализовать. И была безобразно кастрированная
> СУБД, а теперь вообще от СУБД останется одно название.

С чего бы это?
dBASE куда как проще, а тем не менее - самая настоящая СУБД.

Вы специфику СУБД для веба не понимаете. Для большинства хостеров ну вовсе не нужен оверхед ресурсов, а подавляющему числу движков сайтов - ну вовсе не нужны те возможности, что создают этот оверхед.


"В рамках проекта Drizzle начата разработка легковесного варианта MySQL"
Отправлено Аноним , 24-Июл-08 09:33 
>Чтобы что-то убрать, нужно сначала это по-человечески реализовать. И была >безобразно кастрированная СУБД, а теперь вообще от СУБД останется одно название.

идите в сад любезный - есть масса программ которым мускул нужен в режиме записная книжка. Это проги типа DC хабов - всевозможные небольшие самописные служебные программы и т.д.

есть масса задача для которых не нужна полноценная СУБД


"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено Crazy Alex , 24-Июл-08 10:10 
Так в таких программах действительно sqlite место

"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено Гыгыка , 02-Фев-11 17:39 
> Так в таких программах действительно sqlite место

Не-а.
Такие записные книжки, блоги и т.п. бывают иногда ну очень посещаемы.


"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено INM , 24-Июл-08 10:12 
>>Чтобы что-то убрать, нужно сначала это по-человечески реализовать. И была >безобразно кастрированная СУБД, а теперь вообще от СУБД останется одно название.
>
>идите в сад любезный - есть масса программ которым мускул нужен в
>режиме записная книжка. Это проги типа DC хабов - всевозможные небольшие
>самописные служебные программы и т.д.
>
>есть масса задача для которых не нужна полноценная СУБД

Тогда чем sqlite не устраивает?


"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено uldus , 24-Июл-08 10:36 
>Тогда чем sqlite не устраивает?

У sqlite 4 большие проблемы:
1. Решения на его основе не масштабируются
2. Он совершенно не тянет нагрузку, т.е. по одному запросу выполняет нормально, а при необходимости обработки параллельных запросов не годится.
3. у него нет средств кеширования данных, он каждый раз лезет на диск.
4. Это не СУБД, а библиотека.


Drizzle идеален для web-приложений, для которых производительность критична, а все перечисленное в новости совершенно не нужно. Создатели MySQL наконец особнали, что постоянное усложнение до добра не доведет, кося в сторону enterprise, они теряют главную нишу - web.


"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено Жирный Ачкарик , 24-Июл-08 10:54 
> Drizzle идеален для web-приложений, для которых производительность критична

Без query cache? Бгыгы.


"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено Щекн Итрч , 26-Июл-08 16:35 
В жизни не тратил памяти на query cache.
Под высокой нагрузкой он приносит только ущерб.

"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено Veter , 24-Июл-08 11:35 
Вы бы попробовали, прежде чем такие утверждения делать.

1. На кластере используйте репликацию, синхронную или асинхронную. На одном хосте в отличии от других баз при увеличении числа ядер производительность растет _линейно_.
2. Нагрузку держит существенно лучше даже постгреса, не говоря про мускуль. Постгрес на железе типа пентиум Д с саташным винтом держит порядка 150-200 средней сложности транзакций в секунду, эскулайт минимум на порядок больше.
3. Вы про кэширование чтения или записи? Если про чтение, есть shared cache, который следует включить для этой цели. Если про кэширование записи - после завершения транзакции данные принудительно сбрасываются на диск, хотя это можно отключить директивами PRAGMA.
4. Библиотека тоже может быть СУБД. Только эта СУБД из класса встраиваемых.


"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено Phil Kulin , 24-Июл-08 12:46 
> Нагрузку держит существенно лучше даже постгреса, не говоря про мускуль.

Прошу прощения, но мускуль пока ещё был всё же легче постгреса

И ещё раз прошу прощения, а что у нас с конкурентными запросами в sqlite?


"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено INM , 24-Июл-08 12:52 
http://www.sqlite.org/faq.html
http://www.sqlite.org/features.html
Думаю найдете ответы на все свои вопросы.

"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено Phil Kulin , 24-Июл-08 12:55 
>Думаю найдете ответы на все свои вопросы.

Мы наверное с разных планет. Не нашёл ни одного положительного ответа. Подскажите, что я делаю не так?


"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено Veter , 24-Июл-08 13:28 
>> Нагрузку держит существенно лучше даже постгреса, не говоря про мускуль.
>
>Прошу прощения, но мускуль пока ещё был всё же легче постгреса

Мускуль легче, проще, хуже держит нагрузку и медленнее на комплексных запросах. Последнее зависит не от "легкости", а от планировщика. Тема не раз обсуждалась, найти результаты тестирования проблем не составит. Хотя замечу, что если у вас выборки без объединения таблиц, мускуль быстрее. При объединении нескольких таблиц быстрее постгрес. Зато мускуль админить проще, репликация есть, очень много пользователей и легко найти информацию.

>И ещё раз прошу прощения, а что у нас с конкурентными запросами
>в sqlite?

Запросы на чтение могут выполняться одновременно, на запись - последовательно. Если вы хотите создать очередь запросов, используйте функцию sqlite3_busy_timeout. Замечу, что на саташных винтах очередь запросов на запись работает много эффективнее, чем куча конкурентных запросов к диску. Учитывая, что одна транзакция занимает от 500 микросекунд, можно выполнять сотни запросов на запись плюс тысячи на чтение в секунду. Учитывая возможность эскулайта присоединять к открытой базе другие базы (по умолчанию 10 баз, а лимит на 32-бит машине 30 баз), можно партишионировать базу (например, отдельная база на каждый филиал компании) и получать производительность еще выше, сохраняя возможность строить отчеты по данным из всех баз совместно.

Если у вас нагрузка более сотен запросов на запись в секунду, можно создавать базу в ОЗУ. Например, хранение сессионной информации выгодно делать именно так, а при запуске/останове сервера приложений копировать базу с диска/на диск.


"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено uldus , 24-Июл-08 13:32 
>Вы бы попробовали, прежде чем такие утверждения делать.

Я как-то пытался поднять RT на sqlite, рассудив, что для такой задачи MySQL будет как из пушки по воробьям. К тому времени как в базе накопилось около 1000 тикетов, что само по себе смехотворная цифра, размер базы был около 2 Мб, каждая операция занимала по несколько секунд. После того как заменили sqlite на MySQL, все стало летать, нагрузка на сервер упала до нуля. Вторая попытка была с поднятием какого-то web-форума (название из головы вылетело)  с базой на sqlite, все повторилось точь в точь, вначале все гладко, но как только увеличивается объем данных и начинают появляться параллельные запросы - тормозит по страшному.


"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено Veter , 24-Июл-08 15:06 
>[оверквотинг удален]
>Я как-то пытался поднять RT на sqlite, рассудив, что для такой задачи
>MySQL будет как из пушки по воробьям. К тому времени как
>в базе накопилось около 1000 тикетов, что само по себе смехотворная
>цифра, размер базы был около 2 Мб, каждая операция занимала по
>несколько секунд. После того как заменили sqlite на MySQL, все стало
>летать, нагрузка на сервер упала до нуля. Вторая попытка была с
>поднятием какого-то web-форума (название из головы вылетело)  с базой на
>sqlite, все повторилось точь в точь, вначале все гладко, но как
>только увеличивается объем данных и начинают появляться параллельные запросы - тормозит
>по страшному.

Даже не знаю, что вам сказать... чтоб не обидеть :-) По личному опыту - базы эскулайт до 100 гиг работают очень быстро. Большие базы не проверял, будет под рукой свободный винт на терабайт, проверю.


"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено uldus , 24-Июл-08 15:29 
>Даже не знаю, что вам сказать... чтоб не обидеть :-) По личному
>опыту - базы эскулайт до 100 гиг работают очень быстро. Большие
>базы не проверял, будет под рукой свободный винт на терабайт, проверю.

Вполне может быть, что описанные мной проблемы SQLite наблюдаются только во FreeBSD или являются ошибкой в определенной версии, я использовал SQLite 3.2.x.



"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено Veter , 24-Июл-08 16:15 
>>Даже не знаю, что вам сказать... чтоб не обидеть :-) По личному
>>опыту - базы эскулайт до 100 гиг работают очень быстро. Большие
>>базы не проверял, будет под рукой свободный винт на терабайт, проверю.
>
>Вполне может быть, что описанные мной проблемы SQLite наблюдаются только во FreeBSD
>или являются ошибкой в определенной версии, я использовал SQLite 3.2.x.

В указанной вами версии блокировка конкурентного доступа на внутреннем мьютексе работала очень плохо, следовало использовать блокировку на уровне вызывающего приложения (сервера приложений).

А вообще это было лет эдак пять назад, вы бы сравнивали и с мускулем версии 3.х.

Сейчас в эскулайте аналог PostGIS есть с индексом b-tree, полнотекстовый поиск (и не как в постгресе, где скорость его работы такая, что в вебе применить нереально) и еще много возможностей enterprize уровня. Плюс возможность репликации базы с сервера на мобильные устройства и обратно, репликации в память и т.п.


"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено толик , 27-Июл-08 23:45 
>[оверквотинг удален]
>плохо, следовало использовать блокировку на уровне вызывающего приложения (сервера приложений).
>
>А вообще это было лет эдак пять назад, вы бы сравнивали и
>с мускулем версии 3.х.
>
>Сейчас в эскулайте аналог PostGIS есть с индексом b-tree, полнотекстовый поиск (и
>не как в постгресе, где скорость его работы такая, что в
>вебе применить нереально) и еще много возможностей enterprize уровня. Плюс возможность
>репликации базы с сервера на мобильные устройства и обратно, репликации в
>память и т.п.

Veter, ну не знаю даже что сказать. Лайт этот тормоз невероятный на всех операционках. Не надо народ вводить в заблуждение! Мы тестировали его и на Windows, и на OS X и на линуксах. Картина везде абсолютно одинаковая. Был бы лайт коммерческия - я б сказал что ты засланный казачок :)

Полнотекстный поиск в лайте реализован топорно, почитайте их Вики. Просто добавили таблицы вспомагательные и шмалят туда инфу.

Вас послушать мистер Ветер, так в 300 Кб кода Лайт решили все те задачи что занимают десятки метров во взрослых базах, причем на порядок быстрее. Ну ты сам подумай о чем говориш да? Тогда Ораклу, Саю, МС СКЛ и прочем ловить просто нечего сегодня! Так по твоей логике? :-)


"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено Умный , 24-Июл-08 18:36 
> Даже не знаю, что вам сказать... чтоб не обидеть :-)

бакула на sqlite при нескольких лямах записей в базе и объёме в 5Гб никак не работала, тока винтом шуршала. Пришлось от sqlite отказаться. Да, кстати, а есть у sqlite аналог repair или ещё чего-нить чтобы целостность восстановить?


"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено толик , 27-Июл-08 23:31 
>Вы бы попробовали, прежде чем такие утверждения делать.
>
>1. На кластере используйте репликацию, синхронную или асинхронную. На одном хосте в
>отличии от других баз при увеличении числа ядер производительность растет _линейно_.

ну пробовали. Я не понимаю чего такую пургу гнать?
Лайт ваще однопоточный внутри - о чем ты тут рассказываеш?!
Посмотри исходники или хотя бы доку почитай ламер  

>2. Нагрузку держит существенно лучше даже постгреса, не говоря про мускуль. Постгрес
>на железе типа пентиум Д с саташным винтом держит порядка 150-200
>средней сложности транзакций в секунду, эскулайт минимум на порядок больше.

да расскажи!  :-)  Может быть на тех ихних примерах в 1000 записей?
Ваще пародия у них на сайте.

Лайт загибается уже если в базе есть несколько тыс записей.
Может ты просто гонял тупой запрос на одной таблице типа WHERE fld = X
а ты попробуй прогнать что нибудь типа джойна на 5-10 таблицах или агрегацию на джойнах.
Лайт в принципе не имеет блокировок записей! Так что как он тебе отработает паралельно что то ?

Если кто то хочет увидеть настоящую скорость пацаны, попробуйте Valentina базочку.
Она жарит mySQL/MS SQL/Oracle в 50-100 (!!!) раз. Сам не верил пока не проверил!
Смотри здесь http://www.valentina-db.com

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


"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено Гыгыка , 02-Фев-11 17:40 
>>Тогда чем sqlite не устраивает?
> У sqlite 4 большие проблемы:
> 1. Решения на его основе не масштабируются
> 2. Он совершенно не тянет нагрузку, т.е. по одному запросу выполняет нормально,
> а при необходимости обработки параллельных запросов не годится.
> 3. у него нет средств кеширования данных, он каждый раз лезет на
> диск.
> 4. Это не СУБД, а библиотека.

4. Попрошу не оскорблять. Есть весьма сурьезные библиотеки-СУБД. То же FireBird


"В рамках проекта Drizzle начата разработка легковесного варианта MySQL"
Отправлено Аноним , 24-Июл-08 10:49 
От мне какраз такая легкая "записная книжка" очень нужна, так что я "за" такой проект

"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено ононим , 24-Июл-08 11:20 
>От мне какраз такая легкая "записная книжка" очень нужна, так что я
>"за" такой проект

сделай эту записную книжку на LDAP


"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено Гыгыка , 02-Фев-11 17:41 
>>От мне какраз такая легкая "записная книжка" очень нужна, так что я
>>"за" такой проект
> сделай эту записную книжку на LDAP

livejournal.com ?


"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено Ноним , 24-Июл-08 11:37 
>От мне какраз такая легкая "записная книжка" очень нужна, так что я
>"за" такой проект

Кури sqlite


"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено Гыгыка , 02-Фев-11 18:24 
>>От мне какраз такая легкая "записная книжка" очень нужна, так что я
>>"за" такой проект
> Кури sqlite

Йа-йа, натурлих. Особенно на реальном посещаемом веб-сайте.
Пионерия, что с вас взять...


"В рамках проекта Drizzle начата разработка легковесного варианта MySQL"
Отправлено zuborg , 24-Июл-08 12:50 
Все понимаю, можно облегчить, согласен.
Но Query cache то можно было оставить, иначе получится полное пэ

"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено Гыгыка , 02-Фев-11 18:25 
> Все понимаю, можно облегчить, согласен.
> Но Query cache то можно было оставить, иначе получится полное пэ

Они же как решение для облаков толкают.
А query cache памяти ой как немало кушает.


"В рамках проекта Drizzle начата разработка легковесного варианта MySQL"
Отправлено Аноним , 24-Июл-08 14:56 
форк?

"OpenNews: В рамках проекта Drizzle начата разработка легкове..."
Отправлено User294 , 26-Июл-08 19:00 
>и других утяжеляющих работу MySQL возможностей.

И нахрена оно такое нужно когда sqlite его на данном поле по легковесности натянет как тузик грелку?


"OpenNews: В рамках проекта Drizzle начата разработка легкове..."
Отправлено Гыгыка , 02-Фев-11 18:26 
>>и других утяжеляющих работу MySQL возможностей.
> И нахрена оно такое нужно когда sqlite его на данном поле по
> легковесности натянет как тузик грелку?

Я Вам больше скажу - есть еще FoxPro...
Очень быстрый.
На ОДНОМ пользователе.


"В рамках проекта Drizzle начата разработка легковесного варианта MySQL"
Отправлено дядя , 20-Дек-08 03:46 
Может они еще исключат SQL из MySQL чтобы не утяжелял работу ? :)

"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено geekkoo , 05-Мрт-09 15:52 
>Может они еще исключат SQL из MySQL чтобы не утяжелял работу ?
>:)

Кстате, офигенно правильная мысль.


"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено Гыгыка , 02-Фев-11 18:28 
>>Может они еще исключат SQL из MySQL чтобы не утяжелял работу ?
>>:)
> Кстате, офигенно правильная мысль.

Уже реализовано:

Плуг-ин HandlerSocket для MySQL
http://l-o-n-g.livejournal.com/153756.html


"В рамках проекта Drizzle начата разработка легковесного вари..."
Отправлено Гыгыка , 02-Фев-11 18:28 
> Может они еще исключат SQL из MySQL чтобы не утяжелял работу ?
> :)

Этим другие проекты занимаются.
А для Drizzle - полноценный SQL принципиально должен быть.