| 1.1, gutmann (?), 21:18, 24/03/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
"Сначала добавим туда SQL, а потом, когда почти все пользователи этой БД будут писать запросы через SQL, то можно заменять (хоронить) её на SQLite" - подумал Ларри.
| | |
| |
| 2.5, uldus (ok), 00:20, 25/03/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>Чем плоха SQLite?
Проблемы при большой интенсивности записи и при высоком уровне параллельности запросов. Не так давно разработчики KDE рассказывали почему в Akonadi перешли от SQLite к MySQL (http://techbase.kde.org/Projects/PIM/Akonadi#Why_not_use_sqlite.3F):
Why not use sqlite?
We tried. Really. It can't handle the concurrent access very well, in the best case this means very slow operations, but we've also seen deadlocks and failing transactions. Once that's fixed in sqlite, adjusting Akonadi to use it again instead of MySQL is no problem.
| | |
| |
| 3.15, Veter (??), 14:38, 25/03/2010 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Не так давно разработчики KDE рассказывали почему в Akonadi перешли от SQLite к MySQL
Болтуны они. Я им писал и предлагал помощь в решении проблем с эскулайт, буде такие существуют. В ответ они заявили что-де проблемы есть, но ни одной назвать не смогли. В рассылку sqlite-users они также не обращались. Подумал сам поправить, глянул их код - ну точь-в-точь индусы, в итоге плюнул и на аконади и на КДЕ4.
| | |
| |
| 4.20, szh (ok), 21:39, 25/03/2010 [^] [^^] [^^^] [ответить] | +/– | http amarok kde org blog archives 812-MySQL-in-Amarok-2-The-Reality html At fi... большой текст свёрнут, показать | | |
| |
| 5.23, Veter (??), 22:35, 25/03/2010 [^] [^^] [^^^] [ответить]
| +/– | |
Вы процитировали кучу слов и ни одного факта. В рассылку разработчики не обращались, тестов не делали. А написать тормозное приложение можно и без баз данных.
Вот только недавно обсуждалось: одни девелопер заявил, что сможет сделать хэш в памяти, работающий быстрее, чем эскулайт с дисковой БД. Не смог. Тесты и обсуждение см. здесь:
http://www.sql.ru/forum/actualthread.aspx?bid=69&tid=745098&pg=1
| | |
| |
| 6.34, funny_falcon (?), 19:25, 02/07/2010 [^] [^^] [^^^] [ответить]
| +/– |
я тестировал.
Простой тест:
скрипт (тогда на питоне) вставляющий строки в таблицу без пауз в транзакции по 50-100 штук
две - три консоли
запускаешь во всех консолях скрипт
ловишь ошибки доступа к файлу, таймауты и прочее
Второй тест:
малюсенькое приложеньеце, грабящее reddit.com
малюсенькая вебморда для поиска по награбленному (с паджинацией)
тормоза физически ощутимы
seige -b (или ab - кому как нравится) - 10req/seq
после переключения на Postgresql заметно ускорилось
| | |
|
|
| 4.21, uldus (ok), 22:09, 25/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
Я имел печальный опыт развертывания RT (http://www.bestpractical.com/rt/) на SQLite. При работе на отдельном весьма неплохом сервере, когда в системе работало даже два пользователя, страницы формировались секунд 5-10. И это при sqlite базе размером 1.5 Мб (я не ошибся, полтора мегабайта) ! Перевели базу на MySQL, который работал на соседнем сервере и одновременно обслуживал местный хостинг, и все стало летать, задержки исчезли.
Похожий эффект наблюдался при попытке поднять не помню уже какой web-форум с базой на SQLite.
| | |
| |
| 5.22, Veter (??), 22:25, 25/03/2010 [^] [^^] [^^^] [ответить]
| +/– | |
sql-запрос к базе 1,5 Мб никак не может выполняться 5-10 секунд, проблема явно в вашем коде. Приводите результаты тестов, если вы действительно видите проблему, а не потроллить решили.
В одном из проектов меня порядка тысячи клиентов документооборота онлайн, пара сот гигов динамического трафика в месяц и база эскулайт в несколько гигабайт (плюс полтерабайта документов в виде файлов в год) - все ок. Мою сборку эскулайт можно получить здесь:
http://sqlite.mobigroup.ru
тесты здесь:
http://geomapx.blogspot.com/search/label/SQLite
Поддержку своих расширений (сжатие для FTS3, работа с ip-адресами и проч.) по мере возможности обеспечиваю в рассылке sqlite-users и на форуме sql.ru
| | |
| |
| 6.24, uldus (ok), 22:57, 25/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
>sql-запрос к базе 1,5 Мб никак не может выполняться 5-10 секунд, проблема
>явно в вашем коде.
Проблема явно в блокировках при попытке одновременного обращения нескольких процессов к базе. Про deadlock в sqlite я уже не раз слышал. Код типовой и предельно упрощен (т.е. SELECT список/поле по проиндексированному ключу без подзапросов и сложностей), на других СУБД работает отлично.
>В одном из проектов меня порядка тысячи клиентов документооборота онлайн, пара сот
>гигов динамического трафика в месяц и база эскулайт в несколько гигабайт
http://www.sqlite.org/faq.html
(5) Can multiple applications or multiple instances of the same application access a single database file at the same time?
When SQLite tries to access a file that is locked by another process, the default behavior is to return SQLITE_BUSY. You can adjust this behavior from C code using the sqlite3_busy_handler() or sqlite3_busy_timeout() API functions.
При такой организации блокировки на уровне всей базы в любом случае удел SQLite - однопользовательские системы. Или специально под SQLite писать программу с оглядкой на диспетчеризацию запросов.
В http://www.sqlite.org/lockingv3.html я ничего кардинально улучшающее ситуацию с блокировками не нашел.
>тесты здесь:
>http://geomapx.blogspot.com/search/label/SQLite
Это линейные тесты, вы измеряйте скорость последовательного выполнения действий. Протестируйте, что будет при большом конкурирующем числе одновременных обращений.
| | |
| |
| 7.25, Veter (??), 23:52, 25/03/2010 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Про deadlock в sqlite я уже не раз слышал. ...
Улыбнуло. Где тесты?
> При такой организации блокировки на уровне всей базы в любом случае удел SQLite - однопользовательские системы...
Про "однопользовательские системы", наверное, описка. Или 1000 конкурирующих процессов одного пользователя не считается?..
В жестком диске одна головка пишет в один поток - делаете ли вывод, что удел жестких дисков - однозадачные системы? А одноядерный процессор может выполнять только одну процессорную инструкцию одновременно - делаете ли вы вывод, что такие процессоры - только для однозадачных систем?
Ровно так же есть встроенная очередь запросов в эскулайте. Посмотрите sqlite3_busy_timeout(), о котором сказано в процитированном вами фрагменте.
> Протестируйте, что будет при большом конкурирующем числе одновременных обращений.
Тестировал на сотне _одновременных_ обращений. Все ок, уже года два как. Ранее были определенные проблемы, которые я ловил тестами и решал с апстримом - но все давно починили. Впрочем, и до этого вовсю использовал эскулайт в нагруженных веб-сервисах, только приходилось применять разные хитрости, которые теперь не нужны.
В качестве послесловия: если вы во времена ядра 2.4 на какие-то грабли встали, это вовсе не означает, что они есть и сейчас. Попробуйте последние версии эскулайт.
| | |
| |
| 8.26, uldus (ok), 11:05, 26/03/2010 [^] [^^] [^^^] [ответить] | +/– | Я вам про реальные приложения, а вы мне про синтетические тесты Поставьте RT, п... большой текст свёрнут, показать | | |
| |
| 9.27, Veter (??), 11:54, 26/03/2010 [^] [^^] [^^^] [ответить] | +/– | Еще раз - реальные приложения - мои веб-системы с тучей конкурентных юзеров У э... большой текст свёрнут, показать | | |
| |
| |
| 11.29, Veter (??), 12:21, 26/03/2010 [^] [^^] [^^^] [ответить] | +/– | Так это задача ОС - первому дать квант времени тому процессу, который дольше все... текст свёрнут, показать | | |
| |
| 12.30, uldus (ok), 14:07, 26/03/2010 [^] [^^] [^^^] [ответить] | +/– | Это не то, пока заблокировавший базу процесс будет работать с данными планировщи... текст свёрнут, показать | | |
| |
| 13.31, Veter (??), 14:45, 26/03/2010 [^] [^^] [^^^] [ответить] | +/– | При _подключении_ открывает файл Если в каждом коннекте только один запрос, то ... текст свёрнут, показать | | |
| |
| 14.32, uldus (ok), 14:55, 26/03/2010 [^] [^^] [^^^] [ответить] | +/– | Если открывает при подключении, то и база остается заблокированной на весь сеанс... текст свёрнут, показать | | |
| |
| 15.33, Veter (??), 15:18, 26/03/2010 [^] [^^] [^^^] [ответить] | +/– | Нет, с чего бы Пока мы не начнем модифицирующую транзакцию, никакой блокировки ... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| |
| 3.9, Аноним (9), 04:48, 25/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
 И чем он так плох? Не флейма ради, просто любопытно. Давно уже ничего не слышал про него, а недавно вот вспомнил... :-)
| | |
| |
| 4.10, Анонимко (?), 06:54, 25/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
Требует слишком много внимания к себе.
Недавно я на одном сервере, которому именно firebird нужен, в планировщике перезагрузку сервера закомментировал. Думаю, в течение недели еще успею услышать немного матов на тему скорости работы сервера.
Базу раз в неделю пережимаю и возвращаю на место, после чего перезагружаюсь. Таких СУБД мне не нужно.
| | |
| |
| 5.11, Sokoloff (?), 10:09, 25/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
Странно, у меня уже много лет используется firebird, вообще никакого ухода не требует. Работает себе и работает.
| | |
| 5.12, turbouser (?), 10:41, 25/03/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
если база или софт ее использующий кривыми руками спроектирована - нечего пенять на сам firebird
| | |
| 5.19, Аноним (19), 19:58, 25/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
 Можно ли узнать, что это за задача, что Достойнейшая Птичка базу за неделю раздувает, и требует внимания администратора?
Описание в студию!
| | |
|
| 4.14, pro100master (ok), 14:13, 25/03/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> И чем он так плох? Не флейма ради, просто любопытно. Давно уже ничего не слышал про него, а недавно вот вспомнил... :-)
плох тем, что не терпит ламеров и не прощает им ошибок. Так же и в оракле.
Работаем с ib/fb/oracle еще с прошлого тысячелетия :)
| | |
| |
| 5.17, Ы (?), 16:50, 25/03/2010 [^] [^^] [^^^] [ответить]
| +/– | |
Ню-ню - расскажи о вкусе устриц тем кто их и в самом деле ел! :)
Что в Оракле тоже никогда не знаешь восстановится база из отмеченного как успешный из бакапа или нет? Что оракАл вылетает сам от любого чиха? Ну и под конец расскажи что у оракала токое же ... хмм ... скажем оригинальное понимание стандарта SQL?
Дело конечно хозяйское. Но лучше уж MySQL который тоже еще то ГГ - чем FB который в RDBMS есть абсолютное зло и мега ГГ. ____НЕ____ IMHO!
| | |
| |
| 6.18, pro100master (ok), 17:46, 25/03/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> Дело конечно хозяйское. Но лучше уж MySQL который тоже еще то ГГ
ну вот, а говорил, что ел. Не знаешь вкуса устриц :) MySQL ___встраиваемый___ это псц и по деньгам, и по стабильности. Плавали.
А летит всё. С Oracle только одно хорошо - это приложение само в себе - т.е. приложение можно сделать (и делаем) полностью рабочим на сервере. А вот общая стоимость владения, особенно на распределенных, заставляет искать варианты.
| | |
|
|
|
|
|
| 1.7, Аноним (-), 02:44, 25/03/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
> Основным улучшением новой версии является поддержка SQL API
Надеюсь эта поддержка отключается при компиляции.
| | |
| |
| 2.16, Аноним (-), 15:10, 25/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
>API
>API
>API
Просто внешний бинарник, предоставляющий интерфейс sql.
| | |
|
| 1.13, hizel (ok), 11:18, 25/03/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
у них была какая-та нашлепка которая делала из sql запроса код, видимо теперь все из коропке : )
| | |
|
