| 1.1, Oles (?), 00:51, 24/07/2008 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 Бесполезный проект. Даже не могу представить что те, которых MySQL устраивает, по-чему то захотят его "облегчать".
| | |
| |
| 2.3, Аноним (3), 01:02, 24/07/2008 [^] [^^] [^^^] [ответить]
| +/– |
 Нас (scribd.com) - устроит, facebook и fotolog (сегодня спрашивал у них) - тоже устроит :-)
| | |
| |
| 3.5, Oles (?), 01:43, 24/07/2008 [^] [^^] [^^^] [ответить]
| +/– |
>Нас (scribd.com) - устроит, facebook и fotolog (сегодня спрашивал у них) -
>тоже устроит :-)
Ради чего? На чём экономим?
| | |
| |
| 4.37, User294 (ok), 19:04, 26/07/2008 [^] [^^] [^^^] [ответить]
| +/– | |
>Ради чего? На чём экономим?
Если уж нужна легкая БД без крутых фич - тут по-моему выигрышно смотрится sqlite который юзают все кому не лень.Он вообще не клиент-сервер и вся библа - 300 кил кода.Вместе движком бд и поддержкой довольно большого набора SQL, база одним файлом.Итого самое оно для применений где фич обычного MySQL слишком много, IMHO.
| | |
| |
| 5.44, Гыгыка (?), 17:32, 02/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
>>Ради чего? На чём экономим?
> Если уж нужна легкая БД без крутых фич - тут по-моему выигрышно
> смотрится sqlite который юзают все кому не лень.Он вообще не клиент-сервер
> и вся библа - 300 кил кода.Вместе движком бд и поддержкой
> довольно большого набора SQL, база одним файлом.Итого самое оно для применений
> где фич обычного MySQL слишком много, IMHO.
Для ОДИНОЧНОГО пользователя\процесса - да.
Для МАЛЮСЕНЬКОГО сайта с МИЗЕРНОЙ посещаемостью - да.
SQLite неспособна параллельно обрабатывать даже средне нагруженные сайты.
Проверь сам что будет, если ты будешь одновременно читать из SQLite и писать. Тестани эдак на 10 читателях и 3 писателях хотя бы. Если не глуп, то поймешь, что SQLite - недоСУБД. Правда, ты очень удивишься, что и разработчики SQLite это не скрывают.
| | |
|
|
| 3.6, Alrond (??), 03:49, 24/07/2008 [^] [^^] [^^^] [ответить]
| +/– |
 Кстати, оффтоп, но поздравляю с новой, кажется интересной, работой.
Как первый шаг, перевод на nginx вижу уже произошел :)
| | |
|
| 2.42, Гыгыка (?), 17:29, 02/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
А те - кого он не устраивает?
Например, я реально не понимаю - за каким на сравнительно простых запросах и небольшом числе пользователей он там много жрет ресурсов
| | |
|
| |
| 2.43, Гыгыка (?), 17:29, 02/02/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> Хм, возвращение к 3.x?
С чего бы это?
Развитый язык SQL - остается.
| | |
|
| 1.8, tty01 (?), 07:03, 24/07/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Ха-ха. Нет, это просто смешно. Когда MySQL был 3.23, многие выбирали его из-за высокой скорости отдачи запросов, простоты установки, отсутствия триггеров, хранимых процедур. Сегодня MySQL оброс множеством функций, что делает его непригодным в ряде проектов, и поэтому создается облегченная версия MySQL - Drizzle.
Вопрос - сколько пройдет времени, прежде чем появится облегченная версия Drizzle?
| | |
| |
| 2.45, Гыгыка (?), 17:34, 02/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Ха-ха. Нет, это просто смешно. Когда MySQL был 3.23, многие выбирали его
> из-за высокой скорости отдачи запросов, простоты установки, отсутствия триггеров, хранимых
> процедур. Сегодня MySQL оброс множеством функций, что делает его непригодным в
> ряде проектов, и поэтому создается облегченная версия MySQL - Drizzle.
> Вопрос - сколько пройдет времени, прежде чем появится облегченная версия Drizzle?
Как выяснилось - первый официально стабильный релиз спустя 2 года
| | |
|
| |
| |
| 3.14, Cosgor (?), 10:05, 24/07/2008 [^] [^^] [^^^] [ответить]
| +/– | |
>Тригеры в нем есть :) Не подходит :)
<cut>в котором будет убрана поддержка некоторых типов данных, хранимых процедур, триггеров </cut> :] ^^^^^^^^^^^ ^^^^^^^^
| | |
| |
| 4.46, Гыгыка (?), 17:35, 02/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
>>Тригеры в нем есть :) Не подходит :)
> <cut>в котором будет убрана поддержка некоторых типов данных, хранимых процедур, триггеров
> </cut> :] ^^^^^^^^^^^
>
>
>
>
> ^^^^^^^^
В SQLite тригеры есть.
| | |
|
|
|
| 1.11, Все тот же аноним (?), 08:59, 24/07/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Чтобы что-то убрать, нужно сначала это по-человечески реализовать. И была безобразно кастрированная СУБД, а теперь вообще от СУБД останется одно название.
| | |
| |
| 2.47, Гыгыка (?), 17:38, 02/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Чтобы что-то убрать, нужно сначала это по-человечески реализовать. И была безобразно кастрированная
> СУБД, а теперь вообще от СУБД останется одно название.
С чего бы это?
dBASE куда как проще, а тем не менее - самая настоящая СУБД.
Вы специфику СУБД для веба не понимаете. Для большинства хостеров ну вовсе не нужен оверхед ресурсов, а подавляющему числу движков сайтов - ну вовсе не нужны те возможности, что создают этот оверхед.
| | |
|
| 1.12, Аноним (12), 09:33, 24/07/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>Чтобы что-то убрать, нужно сначала это по-человечески реализовать. И была >безобразно кастрированная СУБД, а теперь вообще от СУБД останется одно название.
идите в сад любезный - есть масса программ которым мускул нужен в режиме записная книжка. Это проги типа DC хабов - всевозможные небольшие самописные служебные программы и т.д.
есть масса задача для которых не нужна полноценная СУБД
| | |
| |
| |
| 3.48, Гыгыка (?), 17:39, 02/02/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> Так в таких программах действительно sqlite место
Не-а.
Такие записные книжки, блоги и т.п. бывают иногда ну очень посещаемы.
| | |
|
| 2.16, INM (??), 10:12, 24/07/2008 [^] [^^] [^^^] [ответить]
| +/– |
 >>Чтобы что-то убрать, нужно сначала это по-человечески реализовать. И была >безобразно кастрированная СУБД, а теперь вообще от СУБД останется одно название.
>
>идите в сад любезный - есть масса программ которым мускул нужен в
>режиме записная книжка. Это проги типа DC хабов - всевозможные небольшие
>самописные служебные программы и т.д.
>
>есть масса задача для которых не нужна полноценная СУБД
Тогда чем sqlite не устраивает?
| | |
| |
| 3.17, uldus (ok), 10:36, 24/07/2008 [^] [^^] [^^^] [ответить]
| +/– | |
>Тогда чем sqlite не устраивает?
У sqlite 4 большие проблемы:
1. Решения на его основе не масштабируются
2. Он совершенно не тянет нагрузку, т.е. по одному запросу выполняет нормально, а при необходимости обработки параллельных запросов не годится.
3. у него нет средств кеширования данных, он каждый раз лезет на диск.
4. Это не СУБД, а библиотека.
Drizzle идеален для web-приложений, для которых производительность критична, а все перечисленное в новости совершенно не нужно. Создатели MySQL наконец особнали, что постоянное усложнение до добра не доведет, кося в сторону enterprise, они теряют главную нишу - web.
| | |
| |
| 4.19, Жирный Ачкарик (?), 10:54, 24/07/2008 [^] [^^] [^^^] [ответить]
| +/– | |
> Drizzle идеален для web-приложений, для которых производительность критична
Без query cache? Бгыгы.
| | |
| |
| 5.35, Щекн Итрч (?), 16:35, 26/07/2008 [^] [^^] [^^^] [ответить]
| +/– |
В жизни не тратил памяти на query cache.
Под высокой нагрузкой он приносит только ущерб.
| | |
|
| 4.21, Veter (??), 11:35, 24/07/2008 [^] [^^] [^^^] [ответить]
| +/– | |
Вы бы попробовали, прежде чем такие утверждения делать.
1. На кластере используйте репликацию, синхронную или асинхронную. На одном хосте в отличии от других баз при увеличении числа ядер производительность растет _линейно_.
2. Нагрузку держит существенно лучше даже постгреса, не говоря про мускуль. Постгрес на железе типа пентиум Д с саташным винтом держит порядка 150-200 средней сложности транзакций в секунду, эскулайт минимум на порядок больше.
3. Вы про кэширование чтения или записи? Если про чтение, есть shared cache, который следует включить для этой цели. Если про кэширование записи - после завершения транзакции данные принудительно сбрасываются на диск, хотя это можно отключить директивами PRAGMA.
4. Библиотека тоже может быть СУБД. Только эта СУБД из класса встраиваемых.
| | |
| |
| 5.24, Phil Kulin (?), 12:46, 24/07/2008 [^] [^^] [^^^] [ответить]
| +/– |
 > Нагрузку держит существенно лучше даже постгреса, не говоря про мускуль.
Прошу прощения, но мускуль пока ещё был всё же легче постгреса
И ещё раз прошу прощения, а что у нас с конкурентными запросами в sqlite?
| | |
| |
| |
| 7.27, Phil Kulin (?), 12:55, 24/07/2008 [^] [^^] [^^^] [ответить]
| +/– | |
>Думаю найдете ответы на все свои вопросы.
Мы наверное с разных планет. Не нашёл ни одного положительного ответа. Подскажите, что я делаю не так?
| | |
|
| 6.28, Veter (??), 13:28, 24/07/2008 [^] [^^] [^^^] [ответить]
| +/– |
>> Нагрузку держит существенно лучше даже постгреса, не говоря про мускуль.
>
>Прошу прощения, но мускуль пока ещё был всё же легче постгреса
Мускуль легче, проще, хуже держит нагрузку и медленнее на комплексных запросах. Последнее зависит не от "легкости", а от планировщика. Тема не раз обсуждалась, найти результаты тестирования проблем не составит. Хотя замечу, что если у вас выборки без объединения таблиц, мускуль быстрее. При объединении нескольких таблиц быстрее постгрес. Зато мускуль админить проще, репликация есть, очень много пользователей и легко найти информацию.
>И ещё раз прошу прощения, а что у нас с конкурентными запросами
>в sqlite?
Запросы на чтение могут выполняться одновременно, на запись - последовательно. Если вы хотите создать очередь запросов, используйте функцию sqlite3_busy_timeout. Замечу, что на саташных винтах очередь запросов на запись работает много эффективнее, чем куча конкурентных запросов к диску. Учитывая, что одна транзакция занимает от 500 микросекунд, можно выполнять сотни запросов на запись плюс тысячи на чтение в секунду. Учитывая возможность эскулайта присоединять к открытой базе другие базы (по умолчанию 10 баз, а лимит на 32-бит машине 30 баз), можно партишионировать базу (например, отдельная база на каждый филиал компании) и получать производительность еще выше, сохраняя возможность строить отчеты по данным из всех баз совместно.
Если у вас нагрузка более сотен запросов на запись в секунду, можно создавать базу в ОЗУ. Например, хранение сессионной информации выгодно делать именно так, а при запуске/останове сервера приложений копировать базу с диска/на диск.
| | |
|
| 5.29, uldus (ok), 13:32, 24/07/2008 [^] [^^] [^^^] [ответить]
| +/– | |
>Вы бы попробовали, прежде чем такие утверждения делать.
Я как-то пытался поднять RT на sqlite, рассудив, что для такой задачи MySQL будет как из пушки по воробьям. К тому времени как в базе накопилось около 1000 тикетов, что само по себе смехотворная цифра, размер базы был около 2 Мб, каждая операция занимала по несколько секунд. После того как заменили sqlite на MySQL, все стало летать, нагрузка на сервер упала до нуля. Вторая попытка была с поднятием какого-то web-форума (название из головы вылетело) с базой на sqlite, все повторилось точь в точь, вначале все гладко, но как только увеличивается объем данных и начинают появляться параллельные запросы - тормозит по страшному.
| | |
| |
| 6.31, Veter (??), 15:06, 24/07/2008 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>Я как-то пытался поднять RT на sqlite, рассудив, что для такой задачи
>MySQL будет как из пушки по воробьям. К тому времени как
>в базе накопилось около 1000 тикетов, что само по себе смехотворная
>цифра, размер базы был около 2 Мб, каждая операция занимала по
>несколько секунд. После того как заменили sqlite на MySQL, все стало
>летать, нагрузка на сервер упала до нуля. Вторая попытка была с
>поднятием какого-то web-форума (название из головы вылетело) с базой на
>sqlite, все повторилось точь в точь, вначале все гладко, но как
>только увеличивается объем данных и начинают появляться параллельные запросы - тормозит
>по страшному.
Даже не знаю, что вам сказать... чтоб не обидеть :-) По личному опыту - базы эскулайт до 100 гиг работают очень быстро. Большие базы не проверял, будет под рукой свободный винт на терабайт, проверю.
| | |
| |
| 7.32, uldus (ok), 15:29, 24/07/2008 [^] [^^] [^^^] [ответить]
| +/– |
>Даже не знаю, что вам сказать... чтоб не обидеть :-) По личному
>опыту - базы эскулайт до 100 гиг работают очень быстро. Большие
>базы не проверял, будет под рукой свободный винт на терабайт, проверю.
Вполне может быть, что описанные мной проблемы SQLite наблюдаются только во FreeBSD или являются ошибкой в определенной версии, я использовал SQLite 3.2.x.
| | |
| |
| 8.33, Veter (??), 16:15, 24/07/2008 [^] [^^] [^^^] [ответить] | +/– | В указанной вами версии блокировка конкурентного доступа на внутреннем мьютексе ... текст свёрнут, показать | | |
| |
| 9.39, толик (?), 23:45, 27/07/2008 [^] [^^] [^^^] [ответить] | +/– | gt оверквотинг удален Veter, ну не знаю даже что сказать Лайт этот тормоз нев... текст свёрнут, показать | | |
|
|
| 7.34, Умный (?), 18:36, 24/07/2008 [^] [^^] [^^^] [ответить]
| +/– | |
> Даже не знаю, что вам сказать... чтоб не обидеть :-)
бакула на sqlite при нескольких лямах записей в базе и объёме в 5Гб никак не работала, тока винтом шуршала. Пришлось от sqlite отказаться. Да, кстати, а есть у sqlite аналог repair или ещё чего-нить чтобы целостность восстановить?
| | |
|
|
| 5.38, толик (?), 23:31, 27/07/2008 [^] [^^] [^^^] [ответить]
| +/– |
>Вы бы попробовали, прежде чем такие утверждения делать.
>
>1. На кластере используйте репликацию, синхронную или асинхронную. На одном хосте в
>отличии от других баз при увеличении числа ядер производительность растет _линейно_.
ну пробовали. Я не понимаю чего такую пургу гнать?
Лайт ваще однопоточный внутри - о чем ты тут рассказываеш?!
Посмотри исходники или хотя бы доку почитай ламер
>2. Нагрузку держит существенно лучше даже постгреса, не говоря про мускуль. Постгрес
>на железе типа пентиум Д с саташным винтом держит порядка 150-200
>средней сложности транзакций в секунду, эскулайт минимум на порядок больше.
да расскажи! :-) Может быть на тех ихних примерах в 1000 записей?
Ваще пародия у них на сайте.
Лайт загибается уже если в базе есть несколько тыс записей.
Может ты просто гонял тупой запрос на одной таблице типа WHERE fld = X
а ты попробуй прогнать что нибудь типа джойна на 5-10 таблицах или агрегацию на джойнах.
Лайт в принципе не имеет блокировок записей! Так что как он тебе отработает паралельно что то ?
Если кто то хочет увидеть настоящую скорость пацаны, попробуйте Valentina базочку.
Она жарит mySQL/MS SQL/Oracle в 50-100 (!!!) раз. Сам не верил пока не проверил!
Смотри здесь http://www.valentina-db.com
Причем что в ней классно, она может работать и как встраиваемая - то есть бьет лайт, и как нормальный сервер с клиентами из под разных языков. Кстати похоже что делают ее наши хлопцы.
| | |
|
| 4.49, Гыгыка (?), 17:40, 02/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
>>Тогда чем sqlite не устраивает?
> У sqlite 4 большие проблемы:
> 1. Решения на его основе не масштабируются
> 2. Он совершенно не тянет нагрузку, т.е. по одному запросу выполняет нормально,
> а при необходимости обработки параллельных запросов не годится.
> 3. у него нет средств кеширования данных, он каждый раз лезет на
> диск.
> 4. Это не СУБД, а библиотека.
4. Попрошу не оскорблять. Есть весьма сурьезные библиотеки-СУБД. То же FireBird
| | |
|
|
|
| 1.18, Аноним (12), 10:49, 24/07/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
От мне какраз такая легкая "записная книжка" очень нужна, так что я "за" такой проект
| | |
| |
| 2.20, ононим (?), 11:20, 24/07/2008 [^] [^^] [^^^] [ответить]
| +/– |
>От мне какраз такая легкая "записная книжка" очень нужна, так что я
>"за" такой проект
сделай эту записную книжку на LDAP
| | |
| |
| 3.50, Гыгыка (?), 17:41, 02/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
>>От мне какраз такая легкая "записная книжка" очень нужна, так что я
>>"за" такой проект
> сделай эту записную книжку на LDAP
livejournal.com ?
| | |
|
| 2.22, Ноним (?), 11:37, 24/07/2008 [^] [^^] [^^^] [ответить]
| +/– |
>От мне какраз такая легкая "записная книжка" очень нужна, так что я
>"за" такой проект
Кури sqlite
| | |
| |
| 3.51, Гыгыка (?), 18:24, 02/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
>>От мне какраз такая легкая "записная книжка" очень нужна, так что я
>>"за" такой проект
> Кури sqlite
Йа-йа, натурлих. Особенно на реальном посещаемом веб-сайте.
Пионерия, что с вас взять...
| | |
|
|
| 1.25, zuborg (?), 12:50, 24/07/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Все понимаю, можно облегчить, согласен.
Но Query cache то можно было оставить, иначе получится полное пэ
| | |
| |
| 2.52, Гыгыка (?), 18:25, 02/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Все понимаю, можно облегчить, согласен.
> Но Query cache то можно было оставить, иначе получится полное пэ
Они же как решение для облаков толкают.
А query cache памяти ой как немало кушает.
| | |
|
| 1.36, User294 (ok), 19:00, 26/07/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>и других утяжеляющих работу MySQL возможностей.
И нахрена оно такое нужно когда sqlite его на данном поле по легковесности натянет как тузик грелку?
| | |
| |
| 2.53, Гыгыка (?), 18:26, 02/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
>>и других утяжеляющих работу MySQL возможностей.
> И нахрена оно такое нужно когда sqlite его на данном поле по
> легковесности натянет как тузик грелку?
Я Вам больше скажу - есть еще FoxPro...
Очень быстрый.
На ОДНОМ пользователе.
| | |
|
| 1.40, дядя (?), 03:46, 20/12/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Может они еще исключат SQL из MySQL чтобы не утяжелял работу ? :)
| | |
| |
| 2.41, geekkoo (ok), 15:52, 05/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Может они еще исключат SQL из MySQL чтобы не утяжелял работу ?
>:)
Кстате, офигенно правильная мысль.
| | |
| 2.55, Гыгыка (?), 18:28, 02/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Может они еще исключат SQL из MySQL чтобы не утяжелял работу ?
> :)
Этим другие проекты занимаются.
А для Drizzle - полноценный SQL принципиально должен быть.
| | |
|
|
