forum.opennet.ru

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Оглавление

В выпуске Berkeley DB 5.0 появилась поддержка SQL, opennews (?), 24-Мрт-10, (0) [смотреть все]

Сначала добавим туда SQL, а потом, когда почти все пользователи этой БД будут п, gutmann (?), 21:18 , 24-Мрт-10, (1) //

как бы SQLite не пришлось заменять хоронить , Аноним (-), 21:38 , 24-Мрт-10, (2) //

Да ну, брось Живее всех живых, MTTeam (ok), 23:06 , 24-Мрт-10, (3)

Чем плоха SQLite , Анонимъ (?), 00:00 , 25-Мрт-10, (4) //

Проблемы при большой интенсивности записи и при высоком уровне параллельности за, uldus (ok), 00:20 , 25-Мрт-10, (5) //

Болтуны они Я им писал и предлагал помощь в решении проблем с эскулайт, буде та, Veter (??), 14:38 , 25-Мрт-10, (15) –1 //

http amarok kde org blog archives 812-MySQL-in-Amarok-2-The-Reality htmlAt fir, szh (ok), 21:39 , 25-Мрт-10, (20)

Вы процитировали кучу слов и ни одного факта В рассылку разработчики не обращал, Veter (??), 22:35 , 25-Мрт-10, (23)

я тестировал Простой тест скрипт тогда на питоне вставляющий строки в табли, funny_falcon (?), 19:25 , 02-Июл-10, (34)

Я имел печальный опыт развертывания RT http www bestpractical com rt на SQL, uldus (ok), 22:09 , 25-Мрт-10, (21)

sql-запрос к базе 1,5 Мб никак не может выполняться 5-10 секунд, проблема явно в, Veter (??), 22:25 , 25-Мрт-10, (22)

Проблема явно в блокировках при попытке одновременного обращения нескольких проц, uldus (ok), 22:57 , 25-Мрт-10, (24)

Улыбнуло Где тесты Про однопользовательские системы , наверное, описка Или 10, Veter (??), 23:52 , 25-Мрт-10, (25) –1

Я вам про реальные приложения, а вы мне про синтетические тесты Поставьте RT, п, uldus (ok), 11:05 , 26-Мрт-10, (26)

Еще раз - реальные приложения - мои веб-системы с тучей конкурентных юзеров У эс, Veter (??), 11:54 , 26-Мрт-10, (27)

Как SQlite организует такую очередь без общего диспетчера Программы 1 и 2 пр, uldus (ok), 12:09 , 26-Мрт-10, (28)

Так это задача ОС - первому дать квант времени тому процессу, который дольше все, Veter (??), 12:21 , 26-Мрт-10, (29)

Это не то, пока заблокировавший базу процесс будет работать с данными планировщи, uldus (ok), 14:07 , 26-Мрт-10, (30)
При _подключении_ открывает файл Если в каждом коннекте только один запрос, то , Veter (??), 14:45 , 26-Мрт-10, (31)
Если открывает при подключении, то и база остается заблокированной на весь сеанс, uldus (ok), 14:55 , 26-Мрт-10, (32)
Нет, с чего бы Пока мы не начнем модифицирующую транзакцию, никакой блокировки , Veter (??), 15:18 , 26-Мрт-10, (33)

А тогда почему бы не использовать FireBird-embedded , Mna (??), 02:01 , 25-Мрт-10, (6) //

Нииии - дураков нет Ешьте это сами , Аноним (-), 03:09 , 25-Мрт-10, (8) +1 //

И чем он так плох Не флейма ради, просто любопытно Давно уже ничего не слышал , Аноним (9), 04:48 , 25-Мрт-10, (9) //

Требует слишком много внимания к себе Недавно я на одном сервере, которому именн, Анонимко (?), 06:54 , 25-Мрт-10, (10)

Странно, у меня уже много лет используется firebird, вообще никакого ухода не тр, Sokoloff (?), 10:09 , 25-Мрт-10, (11)
если база или софт ее использующий кривыми руками спроектирована - нечего пенять, turbouser (?), 10:41 , 25-Мрт-10, (12) +1
Можно ли узнать, что это за задача, что Достойнейшая Птичка базу за неделю разду, Аноним (19), 19:58 , 25-Мрт-10, (19)

плох тем, что не терпит ламеров и не прощает им ошибок Так же и в оракле Работа, pro100master (ok), 14:13 , 25-Мрт-10, (14)

Ню-ню - расскажи о вкусе устриц тем кто их и в самом деле ел Что в Оракле тож, Ы (?), 16:50 , 25-Мрт-10, (17)

ну вот, а говорил, что ел Не знаешь вкуса устриц MySQL ___встраиваемый___ эт, pro100master (ok), 17:46 , 25-Мрт-10, (18)

Надеюсь эта поддержка отключается при компиляции , Аноним (-), 02:44 , 25-Мрт-10, (7) +1 //

Просто внешний бинарник, предоставляющий интерфейс sql , Аноним (-), 15:10 , 25-Мрт-10, (16)

у них была какая-та нашлепка которая делала из sql запроса код, видимо теперь вс, hizel (ok), 11:18 , 25-Мрт-10, (13)

Сообщения [Сортировка по времени | RSS]

5. "В выпуске Berkeley DB 5.0 появилась поддержка SQL" +/–

Сообщение от uldus (ok), 25-Мрт-10, 00:20

>Чем плоха SQLite?
Проблемы при большой интенсивности записи и при высоком уровне параллельности запросов. Не так давно разработчики KDE рассказывали почему в Akonadi перешли от SQLite к MySQL (http://techbase.kde.org/Projects/PIM/Akonadi#Why_not_use_sql...):

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.

Ответить | Правка | Наверх | Cообщить модератору

15. "В выпуске Berkeley DB 5.0 появилась поддержка SQL" –1 +/–

Сообщение от Veter (??), 25-Мрт-10, 14:38

> Не так давно разработчики KDE рассказывали почему в Akonadi перешли от SQLite к MySQL
Болтуны они. Я им писал и предлагал помощь в решении проблем с эскулайт, буде такие существуют. В ответ они заявили что-де проблемы есть, но ни одной назвать не смогли. В рассылку sqlite-users они также не обращались. Подумал сам поправить, глянул их код - ну точь-в-точь индусы, в итоге плюнул и на аконади и на КДЕ4.

Ответить | Правка | Наверх | Cообщить модератору

20. "В выпуске Berkeley DB 5.0 появилась поддержка SQL" +/–

Сообщение от szh (ok), 25-Мрт-10, 21:39

http://amarok.kde.org/blog/archives/812-MySQL-in-Amarok-2-Th...
At first, SQLite seemed like a good choice. Using transactions, it's decently fast. It's pretty stable (those that complain about odd MySQL bugs should talk to markey, as he, being the SQLite maintainer in 1.4, can attest that SQLite's had its fair share). However, there were a few problems that in the end knocked it out of the running. The first problem is performance. Although for people with small collections it performs fairly well, people with large collections that switched to the MySQL or PostgreSQL backends in A1 would report enormous speed gains when operations performing complex or many queries were performed, such as adding many entries to the playlist, scanning files, or filtering/searching in the collection. Since we want to accommodate users with large collections just as well as those with smaller collections, and since digital music collections aren't getting smaller, the speed increase for our users with large collections was quite important. Many of our developers, after the switch to mysqle (as we call it, though that's not the official name), have noticed huge speed increases in their day-to-day use of A2, so that speed increase is carrying through to the embedded server as well as the normal server. That was the first knock against SQLite.
The other blow for SQLite came for a totally different reason. Many users (myself included) have multiple computers sharing a single Amarok database. Assuming all the computers have access to the music at the same mount point (and a few other things are configured right), this allows you to scan once, play everywhere, update the same ratings no matter where you play it, and more. Even if your aren't sharing the database among multiple computers, many users want their database stored on a particular server for speed, security, or backup reasons. If you think either of these isn't a common use-case, you'd be quite wrong. MySQL and PostrgreSQL were quite happy with this workload. It's a total no-go for SQLite, simply because it's designed for a different purpose. So SQLite had two big knocks against it. K.O.
However, just as we can't rely on the user to set up Strigi/Nepomuk correctly, we can't rely on them to get their tables set up in MySQL or PostgreSQL. So we needed the database to be embeddable, so that it could just work for the user without any setup necessary on their part. MySQL, with libmysqld, had the seeds of this in the 4.1 series, it works decently in 5.0, and it's becoming fully supported (AFAIK) in 5.1. PostgreSQL, on the other hand, does not have any such thing. (They have an interesting and cool concept of their own of embedded SQL though. Update: apparently that is part of the SQL standard. Still pretty cool. Still totally different from what we mean when we are talking about an embedded server.)
So this leaves us with -- as you guessed -- MySQL.

Ответить | Правка | Наверх | Cообщить модератору

23. "В выпуске Berkeley DB 5.0 появилась поддержка SQL" +/–

Сообщение от Veter (??), 25-Мрт-10, 22:35

Вы процитировали кучу слов и ни одного факта. В рассылку разработчики не обращались, тестов не делали. А написать тормозное приложение можно и без баз данных.
Вот только недавно обсуждалось: одни девелопер заявил, что сможет сделать хэш в памяти, работающий быстрее, чем эскулайт с дисковой БД. Не смог. Тесты и обсуждение см. здесь:
http://www.sql.ru/forum/actualthread.aspx?bid=69&tid=745098&...

Ответить | Правка | Наверх | Cообщить модератору

34. "В выпуске Berkeley DB 5.0 появилась поддержка SQL" +/–

Сообщение от funny_falcon (?), 02-Июл-10, 19:25

я тестировал.
Простой тест:
  скрипт (тогда на питоне) вставляющий строки в таблицу без пауз в транзакции по 50-100 штук
  две - три консоли
  запускаешь во всех консолях скрипт
  ловишь ошибки доступа к файлу, таймауты и прочее
Второй тест:
  малюсенькое приложеньеце, грабящее reddit.com
  малюсенькая вебморда для поиска по награбленному (с паджинацией)
  тормоза физически ощутимы
  seige -b (или ab - кому как нравится) - 10req/seq
  после переключения на Postgresql заметно ускорилось

Ответить | Правка | Наверх | Cообщить модератору

21. "В выпуске Berkeley DB 5.0 появилась поддержка SQL" +/–

Сообщение от uldus (ok), 25-Мрт-10, 22:09

Я имел печальный опыт развертывания RT (http://www.bestpractical.com/rt/) на SQLite. При работе на отдельном весьма неплохом сервере, когда в системе работало даже два пользователя, страницы формировались секунд 5-10. И это при sqlite базе размером 1.5 Мб (я не ошибся, полтора мегабайта) ! Перевели базу на MySQL, который работал на соседнем сервере и одновременно обслуживал местный хостинг, и все стало летать, задержки исчезли.
Похожий эффект наблюдался при попытке поднять не помню уже какой web-форум с базой на SQLite.

Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

22. "В выпуске Berkeley DB 5.0 появилась поддержка SQL" +/–

Сообщение от Veter (??), 25-Мрт-10, 22:25

sql-запрос к базе 1,5 Мб никак не может выполняться 5-10 секунд, проблема явно в вашем коде. Приводите результаты тестов, если вы действительно видите проблему, а не потроллить решили.
В одном из проектов меня порядка тысячи клиентов документооборота онлайн, пара сот гигов динамического трафика в месяц и база эскулайт в несколько гигабайт (плюс полтерабайта документов в виде файлов в год) - все ок. Мою сборку эскулайт можно получить здесь:
http://sqlite.mobigroup.ru
тесты здесь:
http://geomapx.blogspot.com/search/label/SQLite
Поддержку своих расширений (сжатие для FTS3, работа с ip-адресами и проч.) по мере возможности обеспечиваю в рассылке sqlite-users и на форуме sql.ru

Ответить | Правка | Наверх | Cообщить модератору

24. "В выпуске Berkeley DB 5.0 появилась поддержка SQL" +/–

Сообщение от uldus (ok), 25-Мрт-10, 22:57

>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
Это линейные тесты, вы измеряйте скорость последовательного выполнения действий. Протестируйте, что будет при большом конкурирующем числе одновременных обращений.

Ответить | Правка | Наверх | Cообщить модератору

25. "В выпуске Berkeley DB 5.0 появилась поддержка SQL" –1 +/–

Сообщение от Veter (??), 25-Мрт-10, 23:52

> Про deadlock в sqlite я уже не раз слышал. ...
Улыбнуло. Где тесты?
> При такой организации блокировки на уровне всей базы в любом случае удел SQLite - однопользовательские системы...
Про "однопользовательские системы", наверное, описка. Или 1000 конкурирующих процессов одного пользователя не считается?..
В жестком диске одна головка пишет в один поток - делаете ли вывод, что удел жестких дисков - однозадачные системы? А одноядерный процессор может выполнять только одну процессорную инструкцию одновременно - делаете ли вы вывод, что такие процессоры - только для однозадачных систем?
Ровно так же есть встроенная очередь запросов в эскулайте. Посмотрите sqlite3_busy_timeout(), о котором сказано в процитированном вами фрагменте.
> Протестируйте, что будет при большом конкурирующем числе одновременных обращений.
Тестировал на сотне _одновременных_ обращений. Все ок, уже года два как. Ранее были определенные проблемы, которые я ловил тестами и решал с апстримом - но все давно починили. Впрочем, и до этого вовсю использовал эскулайт в нагруженных веб-сервисах, только приходилось применять разные хитрости, которые теперь не нужны.
В качестве послесловия: если вы во времена ядра 2.4 на какие-то грабли встали, это вовсе не означает, что они есть и сейчас. Попробуйте последние версии эскулайт.

Ответить | Правка | Наверх | Cообщить модератору

26. "В выпуске Berkeley DB 5.0 появилась поддержка SQL" +/–

Сообщение от uldus (ok), 26-Мрт-10, 11:05

>> Про deadlock в sqlite я уже не раз слышал. ...
>
>Улыбнуло. Где тесты?
Я вам про реальные приложения, а вы мне про синтетические тесты. Поставьте RT, посадите писать тикеты нескольких пользователей - вот вам и тест.
>Про "однопользовательские системы", наверное, описка. Или 1000 конкурирующих процессов одного пользователя не
В SQLite не может быть конкурирующих запросов по определению, в каждый момент времени только один процесс всегда имеет доступ к файлу с базой и данные между процессами не расшариваются и не кешируются. Остальные ждут своей очереди, если процесс агрессивно работает с базой, все остальные курят и ждут, пример - RT.

>В жестком диске одна головка пишет в один поток - делаете ли
>вывод, что удел жестких дисков - однозадачные системы?
В СУБД подобных MySQL работает диспетчеризация запросов, при обработке текущего запроса есть картина об очереди запросов в целом и данные могут кешироваться в памяти, запросы обслуживаются одновременно. В SQLite такой диспетчеризации нет, каждый процесс может только судить есть лок или нет, если база лочится _целиком_ (локов на строки и таблицы там нет) и надолго. Насколько я понимаю и для SQLite такие диспетчеры есть, но подключаются отдельно как надстройки.
>> Протестируйте, что будет при большом конкурирующем числе одновременных обращений.
Обращений на запись/изменение. Пока транзакция не закроется, лок не освободится, остальные будут ждать, не важно, что они хотят поменять данные в другой таблице, правильно я понимаю ?
Возможно я что-то упускаю из вида, поясните мне поведение SQLite на примере.
Есть два процесса, которые работают с базой - 1 и 2. Есть две таблицы в базе - A и B.
Процесс 1 делает серию последовательных апдейтов базы A, процесс 2 чуть опоздав делает апдейт базы B.
Когда для процесса 2 появится возможность внести изменения, может ли он вклинится между серией последовательных апдейтов процесса 1 или будет вынужден ждать до их окончания (если они идут непрерывным потоком) ?
Если вклинится может (как я понял только после истечения таймаута), то что будет с процессом 1 после внесения изменений в базу процессом 2, ему придется перечитывать состояние базы с диска, кэш ведь протухнет, а о сути изменений добавленных процессом 2 процесс 1 ничего не знает ?
Если процесс 2 тоже интенсивно пишет в базу, не получится ли ситуация вечного перечитывания базы с диска при каждом запросе ?
Оптимизация такой ситуации сводится к разносу таблиц А и Б по разным базам ? Но если процессы конкурируют за доступ к одной таблице ?

Ответить | Правка | Наверх | Cообщить модератору

27. "В выпуске Berkeley DB 5.0 появилась поддержка SQL" +/–

Сообщение от Veter (??), 26-Мрт-10, 11:54

> Я вам про реальные приложения, а вы мне про синтетические тесты.
Еще раз - реальные приложения - мои веб-системы с тучей конкурентных юзеров.
> Поставьте RT, посадите писать тикеты нескольких пользователей - вот вам и тест.
У эскулайта есть собственная распределенная система управления исходниками - fossil. Там же есть и тикеты и вики. Работает на оффсайте эскулайта, в том числе. И вот почему-то мне ни разу не приходилось ждать несколько секунд, добавляя тикеты, даже когда анонимное добавление было разрешено и этих тикетов море добавлялось.
> Процесс 1 делает серию последовательных апдейтов базы A,
> процесс 2 чуть опоздав делает апдейт базы B.
Есть понятие транзакционности. Если изменения идут в рамках одной транзакции, то, естественно, между ними "вклиниться" нельзя. Иначе запросы выполняются в порядке их поступления в очередь.
> Если процесс 2 тоже интенсивно пишет в базу, не получится ли ситуация
> вечного перечитывания базы с диска при каждом запросе ?
Зачем всю базу-то читать? Для схемы БД есть маркер последнего изменения, если один из процессов изменил схему БД, остальнам придется схему (и только схему) перечитать. В кэше как раз находится схема БД. Что касается самих данных, они кэшируются ОС и весьма эффективно - я уже приводил ссылку, где проверяется, что работа с дисковой БД не уступает по скорости операциям с кэшем в ОЗУ.
И почему вы так не любите тесты и цифры... На диске 10 000 rpm эскулайт выполняет примерно 100 модифицирующих транзакций в секунду, с гарантией целостности данных. Плюс можно выполнить десятки тысяч операций чтения в секунду. Если нужно больше операций записи - необходимо объединять их в транзакции. Но уже на указанных нагрузках "порвутся" и постгрес и мускуль. Для постгреса, к примеру, несколько сот запросов чтения в секунду - большая нагрузка, несколько тысяч - предельная, а про десятки тысяч и речь не идет, хот ядля эскулайт это совершенно обычная нагрузка. Для веб-проектов типичное соотношение чтение/запись примерно от 1/9 до 1/99, так что эскулайт при 100 записях и 10 000 чтений в секунду отлично подходит.

Ответить | Правка | Наверх | Cообщить модератору

28. "В выпуске Berkeley DB 5.0 появилась поддержка SQL" +/–

Сообщение от uldus (ok), 26-Мрт-10, 12:09

>между ними "вклиниться" нельзя. Иначе запросы выполняются в порядке их поступления
>в очередь.
Как SQlite организует такую очередь без общего диспетчера ??? Программы 1 и 2 прилинкованы к библиотеке, которая при каждом их запуске может судить только о глобальном локе базы (пока файл не будет разлочен, sqlite в нем ничего не сможет поменять), там же нет отдельного хранилища для очереди запросов и для каждого процесса получается своя очередь ?
> Что касается самих данных, они кэшируются ОС и весьма эффективно - я уже приводил ссылку, где проверяется, что работа с дисковой БД не уступает по скорости операциям с кэшем в ОЗУ.
Похоже в этом и было дело, все очень зависит от типа файловой системы и организации кеширования в ОС. Насколько я помню FreeBSD кеширует только мета-данные, видимо в этом и собака порылась.

Ответить | Правка | Наверх | Cообщить модератору

29. "В выпуске Berkeley DB 5.0 появилась поддержка SQL" +/–

Сообщение от Veter (??), 26-Мрт-10, 12:21

>Как SQlite организует такую очередь без общего диспетчера ???
Так это задача ОС - первому дать квант времени тому процессу, который дольше всех ждет. Соответственно, именно этот процесс и выполнит очередную блокировку. При желании можно приоритетами процессов поиграться, но обычно в веб-приложениях все процессы равноценные.
>> Что касается самих данных, они кэшируются ОС и весьма эффективно - я уже приводил ссылку, где проверяется, что работа с дисковой БД не уступает по скорости операциям с кэшем в ОЗУ.
>Похоже в этом и было дело, все очень зависит от типа файловой
>системы и организации кеширования в ОС. Насколько я помню FreeBSD кеширует
>только мета-данные, видимо в этом и собака порылась.
У меня всегда ext3. Кстати, в последних ядрах линукса еще много всего с кэшированием сделали, так что работа с большими базами (намного превосходящими по размеру объем ОЗУ) вроде как должна ускориться.

Ответить | Правка | Наверх | Cообщить модератору

30. "В выпуске Berkeley DB 5.0 появилась поддержка SQL" +/–

Сообщение от uldus (ok), 26-Мрт-10, 14:07

>>Как SQlite организует такую очередь без общего диспетчера ???
>
>Так это задача ОС - первому дать квант времени тому процессу, который
>дольше всех ждет.
Это не то, пока заблокировавший базу процесс будет работать с данными планировщик задач успеет миллион раз отдать управление ожидающим освобождения процессам, а потом начнет сразу выполнение следующего запроса и остальные процессы так и будут ждать освобождения лока.
Вообще интересно конечно провести экперимент, запустить одновременно два процесса, которые в цикле будут делать UPDATE/INSERT случайных полей и посмотреть насколько равномерным получится распределение. Еще можно к тем двум добавить несколько выполняющих SELECT. Тогда сразу все по полкам разложится, насколько эффективно балансировка обращения к базе в SQLite работает.
> Соответственно, именно этот процесс и выполнит очередную блокировку.
Получается, что при каждом запросе sqlite открывает и закрывает файл, а при следующем запросе по сути начинает с чистого листа ?

Ответить | Правка | Наверх | Cообщить модератору

31. "В выпуске Berkeley DB 5.0 появилась поддержка SQL" +/–

Сообщение от Veter (??), 26-Мрт-10, 14:45

> Получается, что при каждом запросе sqlite открывает и закрывает файл,
> а при следующем запросе по сути начинает с чистого листа ?
При _подключении_ открывает файл. Если в каждом коннекте только один запрос, то каждый будет "с чистого листа" - если не используется shared cache и встроенный сервер.
В вебе использую отдельное подключение на каждый HTTP-запрос - т.к. процессор уровня кореквадро
позволяет в секунду инициировать около 8 000 новых подключений к базе, а количество выполняемых HTTP-запросов в разы меньше. Открытие БД занимает несколько сот микросекунд, в зависимости от сложности схемы БД и количества загружаемых расширений.
В принципе, главное - использовать короткие транзакции. Например, делая копию выборки в in-memory таблицу (временную), чтобы на этапе отрисовки веб-страницы и прочей обработки результата не блокировать основную БД от записи. Зато скорость выполнения запросов радует:
http://geomapx.blogspot.com/2009/11/postgresql-81-vs-sqlite-...
Часто получается, что на администрирование нагруженного постгреса больше времени уходит, нежели на написание необходимых расширений к эскулайт.

Ответить | Правка | Наверх | Cообщить модератору

32. "В выпуске Berkeley DB 5.0 появилась поддержка SQL" +/–

Сообщение от uldus (ok), 26-Мрт-10, 14:55

>При _подключении_ открывает файл. Если в каждом коннекте только один запрос, то
>каждый будет "с чистого листа" - если не используется shared cache
>и встроенный сервер.
Если открывает при подключении, то и база остается заблокированной на весь сеанс работы или сразу несколько процессов файл с базой на запись открывают и потом координуруют между собой каким-то образом внесение изменений в файл ?
>результата не блокировать основную БД от записи. Зато скорость выполнения запросов
>радует:
>http://geomapx.blogspot.com/2009/11/postgresql-81-vs-sqlite-...
В этом тесте тоже измеряются неконкурирующие отдельные запросы. Попробуйте протестировать работу нескольких конкурирующих процессов с активностью на запись данных.

Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

33. "В выпуске Berkeley DB 5.0 появилась поддержка SQL" +/–

Сообщение от Veter (??), 26-Мрт-10, 15:18

>Если открывает при подключении, то и база остается заблокированной на весь сеанс
Нет, с чего бы. Пока мы не начнем модифицирующую транзакцию, никакой блокировки нет, читать можно из любого числа процессов параллельно. Как только один из процессов вносит изменения, выполняется блокировка и все остальные процессы приостанавливаются до окончания транзакции, после чего продолжают выполнять запросы.
> В этом тесте тоже измеряются неконкурирующие отдельные запросы.
> Попробуйте протестировать работу нескольких
> конкурирующих процессов с активностью на запись данных.
К примеру:
http://geomapx.blogspot.com/2009/11/postgresql-to-sqlite-rep...
Для веб-сервера тестировал от 20-ти до 100 одновременных потоков на чтение/запись, но тесты не выкладывал. Были проблемы примерно до версии эскулайт 3.5.9, о чем я уже упоминал, а сейчас все работает как надо.

Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


	5. "В выпуске Berkeley DB 5.0 появилась поддержка SQL"	+/–
	Сообщение от uldus (ok), 25-Мрт-10, 00:20
	>Чем плоха SQLite? Проблемы при большой интенсивности записи и при высоком уровне параллельности запросов. Не так давно разработчики KDE рассказывали почему в Akonadi перешли от SQLite к MySQL (http://techbase.kde.org/Projects/PIM/Akonadi#Why_not_use_sql...): 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.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	15. "В выпуске Berkeley DB 5.0 появилась поддержка SQL"	–1 +/–
	Сообщение от Veter (??), 25-Мрт-10, 14:38
	> Не так давно разработчики KDE рассказывали почему в Akonadi перешли от SQLite к MySQL Болтуны они. Я им писал и предлагал помощь в решении проблем с эскулайт, буде такие существуют. В ответ они заявили что-де проблемы есть, но ни одной назвать не смогли. В рассылку sqlite-users они также не обращались. Подумал сам поправить, глянул их код - ну точь-в-точь индусы, в итоге плюнул и на аконади и на КДЕ4.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	20. "В выпуске Berkeley DB 5.0 появилась поддержка SQL"	+/–
	Сообщение от szh (ok), 25-Мрт-10, 21:39
	http://amarok.kde.org/blog/archives/812-MySQL-in-Amarok-2-Th... At first, SQLite seemed like a good choice. Using transactions, it's decently fast. It's pretty stable (those that complain about odd MySQL bugs should talk to markey, as he, being the SQLite maintainer in 1.4, can attest that SQLite's had its fair share). However, there were a few problems that in the end knocked it out of the running. The first problem is performance. Although for people with small collections it performs fairly well, people with large collections that switched to the MySQL or PostgreSQL backends in A1 would report enormous speed gains when operations performing complex or many queries were performed, such as adding many entries to the playlist, scanning files, or filtering/searching in the collection. Since we want to accommodate users with large collections just as well as those with smaller collections, and since digital music collections aren't getting smaller, the speed increase for our users with large collections was quite important. Many of our developers, after the switch to mysqle (as we call it, though that's not the official name), have noticed huge speed increases in their day-to-day use of A2, so that speed increase is carrying through to the embedded server as well as the normal server. That was the first knock against SQLite. The other blow for SQLite came for a totally different reason. Many users (myself included) have multiple computers sharing a single Amarok database. Assuming all the computers have access to the music at the same mount point (and a few other things are configured right), this allows you to scan once, play everywhere, update the same ratings no matter where you play it, and more. Even if your aren't sharing the database among multiple computers, many users want their database stored on a particular server for speed, security, or backup reasons. If you think either of these isn't a common use-case, you'd be quite wrong. MySQL and PostrgreSQL were quite happy with this workload. It's a total no-go for SQLite, simply because it's designed for a different purpose. So SQLite had two big knocks against it. K.O. However, just as we can't rely on the user to set up Strigi/Nepomuk correctly, we can't rely on them to get their tables set up in MySQL or PostgreSQL. So we needed the database to be embeddable, so that it could just work for the user without any setup necessary on their part. MySQL, with libmysqld, had the seeds of this in the 4.1 series, it works decently in 5.0, and it's becoming fully supported (AFAIK) in 5.1. PostgreSQL, on the other hand, does not have any such thing. (They have an interesting and cool concept of their own of embedded SQL though. Update: apparently that is part of the SQL standard. Still pretty cool. Still totally different from what we mean when we are talking about an embedded server.) So this leaves us with -- as you guessed -- MySQL.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	23. "В выпуске Berkeley DB 5.0 появилась поддержка SQL"	+/–
	Сообщение от Veter (??), 25-Мрт-10, 22:35
	Вы процитировали кучу слов и ни одного факта. В рассылку разработчики не обращались, тестов не делали. А написать тормозное приложение можно и без баз данных. Вот только недавно обсуждалось: одни девелопер заявил, что сможет сделать хэш в памяти, работающий быстрее, чем эскулайт с дисковой БД. Не смог. Тесты и обсуждение см. здесь: http://www.sql.ru/forum/actualthread.aspx?bid=69&tid=745098&...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	34. "В выпуске Berkeley DB 5.0 появилась поддержка SQL"	+/–
	Сообщение от funny_falcon (?), 02-Июл-10, 19:25
	я тестировал. Простой тест: скрипт (тогда на питоне) вставляющий строки в таблицу без пауз в транзакции по 50-100 штук две - три консоли запускаешь во всех консолях скрипт ловишь ошибки доступа к файлу, таймауты и прочее Второй тест: малюсенькое приложеньеце, грабящее reddit.com малюсенькая вебморда для поиска по награбленному (с паджинацией) тормоза физически ощутимы seige -b (или ab - кому как нравится) - 10req/seq после переключения на Postgresql заметно ускорилось
	Ответить \| Правка \| Наверх \| Cообщить модератору


	21. "В выпуске Berkeley DB 5.0 появилась поддержка SQL"	+/–
	Сообщение от uldus (ok), 25-Мрт-10, 22:09
	Я имел печальный опыт развертывания RT (http://www.bestpractical.com/rt/) на SQLite. При работе на отдельном весьма неплохом сервере, когда в системе работало даже два пользователя, страницы формировались секунд 5-10. И это при sqlite базе размером 1.5 Мб (я не ошибся, полтора мегабайта) ! Перевели базу на MySQL, который работал на соседнем сервере и одновременно обслуживал местный хостинг, и все стало летать, задержки исчезли. Похожий эффект наблюдался при попытке поднять не помню уже какой web-форум с базой на SQLite.
	Ответить \| Правка \| К родителю #15 \| Наверх \| Cообщить модератору


	22. "В выпуске Berkeley DB 5.0 появилась поддержка SQL"	+/–
	Сообщение от Veter (??), 25-Мрт-10, 22:25
	sql-запрос к базе 1,5 Мб никак не может выполняться 5-10 секунд, проблема явно в вашем коде. Приводите результаты тестов, если вы действительно видите проблему, а не потроллить решили. В одном из проектов меня порядка тысячи клиентов документооборота онлайн, пара сот гигов динамического трафика в месяц и база эскулайт в несколько гигабайт (плюс полтерабайта документов в виде файлов в год) - все ок. Мою сборку эскулайт можно получить здесь: http://sqlite.mobigroup.ru тесты здесь: http://geomapx.blogspot.com/search/label/SQLite Поддержку своих расширений (сжатие для FTS3, работа с ip-адресами и проч.) по мере возможности обеспечиваю в рассылке sqlite-users и на форуме sql.ru
	Ответить \| Правка \| Наверх \| Cообщить модератору


	24. "В выпуске Berkeley DB 5.0 появилась поддержка SQL"	+/–
	Сообщение от uldus (ok), 25-Мрт-10, 22:57
	>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 Это линейные тесты, вы измеряйте скорость последовательного выполнения действий. Протестируйте, что будет при большом конкурирующем числе одновременных обращений.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	25. "В выпуске Berkeley DB 5.0 появилась поддержка SQL"	–1 +/–
	Сообщение от Veter (??), 25-Мрт-10, 23:52
	> Про deadlock в sqlite я уже не раз слышал. ... Улыбнуло. Где тесты? > При такой организации блокировки на уровне всей базы в любом случае удел SQLite - однопользовательские системы... Про "однопользовательские системы", наверное, описка. Или 1000 конкурирующих процессов одного пользователя не считается?.. В жестком диске одна головка пишет в один поток - делаете ли вывод, что удел жестких дисков - однозадачные системы? А одноядерный процессор может выполнять только одну процессорную инструкцию одновременно - делаете ли вы вывод, что такие процессоры - только для однозадачных систем? Ровно так же есть встроенная очередь запросов в эскулайте. Посмотрите sqlite3_busy_timeout(), о котором сказано в процитированном вами фрагменте. > Протестируйте, что будет при большом конкурирующем числе одновременных обращений. Тестировал на сотне _одновременных_ обращений. Все ок, уже года два как. Ранее были определенные проблемы, которые я ловил тестами и решал с апстримом - но все давно починили. Впрочем, и до этого вовсю использовал эскулайт в нагруженных веб-сервисах, только приходилось применять разные хитрости, которые теперь не нужны. В качестве послесловия: если вы во времена ядра 2.4 на какие-то грабли встали, это вовсе не означает, что они есть и сейчас. Попробуйте последние версии эскулайт.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	26. "В выпуске Berkeley DB 5.0 появилась поддержка SQL"	+/–
	Сообщение от uldus (ok), 26-Мрт-10, 11:05
	>> Про deadlock в sqlite я уже не раз слышал. ... > >Улыбнуло. Где тесты? Я вам про реальные приложения, а вы мне про синтетические тесты. Поставьте RT, посадите писать тикеты нескольких пользователей - вот вам и тест. >Про "однопользовательские системы", наверное, описка. Или 1000 конкурирующих процессов одного пользователя не В SQLite не может быть конкурирующих запросов по определению, в каждый момент времени только один процесс всегда имеет доступ к файлу с базой и данные между процессами не расшариваются и не кешируются. Остальные ждут своей очереди, если процесс агрессивно работает с базой, все остальные курят и ждут, пример - RT. >В жестком диске одна головка пишет в один поток - делаете ли >вывод, что удел жестких дисков - однозадачные системы? В СУБД подобных MySQL работает диспетчеризация запросов, при обработке текущего запроса есть картина об очереди запросов в целом и данные могут кешироваться в памяти, запросы обслуживаются одновременно. В SQLite такой диспетчеризации нет, каждый процесс может только судить есть лок или нет, если база лочится _целиком_ (локов на строки и таблицы там нет) и надолго. Насколько я понимаю и для SQLite такие диспетчеры есть, но подключаются отдельно как надстройки. >> Протестируйте, что будет при большом конкурирующем числе одновременных обращений. Обращений на запись/изменение. Пока транзакция не закроется, лок не освободится, остальные будут ждать, не важно, что они хотят поменять данные в другой таблице, правильно я понимаю ? Возможно я что-то упускаю из вида, поясните мне поведение SQLite на примере. Есть два процесса, которые работают с базой - 1 и 2. Есть две таблицы в базе - A и B. Процесс 1 делает серию последовательных апдейтов базы A, процесс 2 чуть опоздав делает апдейт базы B. Когда для процесса 2 появится возможность внести изменения, может ли он вклинится между серией последовательных апдейтов процесса 1 или будет вынужден ждать до их окончания (если они идут непрерывным потоком) ? Если вклинится может (как я понял только после истечения таймаута), то что будет с процессом 1 после внесения изменений в базу процессом 2, ему придется перечитывать состояние базы с диска, кэш ведь протухнет, а о сути изменений добавленных процессом 2 процесс 1 ничего не знает ? Если процесс 2 тоже интенсивно пишет в базу, не получится ли ситуация вечного перечитывания базы с диска при каждом запросе ? Оптимизация такой ситуации сводится к разносу таблиц А и Б по разным базам ? Но если процессы конкурируют за доступ к одной таблице ?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	27. "В выпуске Berkeley DB 5.0 появилась поддержка SQL"	+/–
	Сообщение от Veter (??), 26-Мрт-10, 11:54
	> Я вам про реальные приложения, а вы мне про синтетические тесты. Еще раз - реальные приложения - мои веб-системы с тучей конкурентных юзеров. > Поставьте RT, посадите писать тикеты нескольких пользователей - вот вам и тест. У эскулайта есть собственная распределенная система управления исходниками - fossil. Там же есть и тикеты и вики. Работает на оффсайте эскулайта, в том числе. И вот почему-то мне ни разу не приходилось ждать несколько секунд, добавляя тикеты, даже когда анонимное добавление было разрешено и этих тикетов море добавлялось. > Процесс 1 делает серию последовательных апдейтов базы A, > процесс 2 чуть опоздав делает апдейт базы B. Есть понятие транзакционности. Если изменения идут в рамках одной транзакции, то, естественно, между ними "вклиниться" нельзя. Иначе запросы выполняются в порядке их поступления в очередь. > Если процесс 2 тоже интенсивно пишет в базу, не получится ли ситуация > вечного перечитывания базы с диска при каждом запросе ? Зачем всю базу-то читать? Для схемы БД есть маркер последнего изменения, если один из процессов изменил схему БД, остальнам придется схему (и только схему) перечитать. В кэше как раз находится схема БД. Что касается самих данных, они кэшируются ОС и весьма эффективно - я уже приводил ссылку, где проверяется, что работа с дисковой БД не уступает по скорости операциям с кэшем в ОЗУ. И почему вы так не любите тесты и цифры... На диске 10 000 rpm эскулайт выполняет примерно 100 модифицирующих транзакций в секунду, с гарантией целостности данных. Плюс можно выполнить десятки тысяч операций чтения в секунду. Если нужно больше операций записи - необходимо объединять их в транзакции. Но уже на указанных нагрузках "порвутся" и постгрес и мускуль. Для постгреса, к примеру, несколько сот запросов чтения в секунду - большая нагрузка, несколько тысяч - предельная, а про десятки тысяч и речь не идет, хот ядля эскулайт это совершенно обычная нагрузка. Для веб-проектов типичное соотношение чтение/запись примерно от 1/9 до 1/99, так что эскулайт при 100 записях и 10 000 чтений в секунду отлично подходит.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	28. "В выпуске Berkeley DB 5.0 появилась поддержка SQL"	+/–
	Сообщение от uldus (ok), 26-Мрт-10, 12:09
	>между ними "вклиниться" нельзя. Иначе запросы выполняются в порядке их поступления >в очередь. Как SQlite организует такую очередь без общего диспетчера ??? Программы 1 и 2 прилинкованы к библиотеке, которая при каждом их запуске может судить только о глобальном локе базы (пока файл не будет разлочен, sqlite в нем ничего не сможет поменять), там же нет отдельного хранилища для очереди запросов и для каждого процесса получается своя очередь ? > Что касается самих данных, они кэшируются ОС и весьма эффективно - я уже приводил ссылку, где проверяется, что работа с дисковой БД не уступает по скорости операциям с кэшем в ОЗУ. Похоже в этом и было дело, все очень зависит от типа файловой системы и организации кеширования в ОС. Насколько я помню FreeBSD кеширует только мета-данные, видимо в этом и собака порылась.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	29. "В выпуске Berkeley DB 5.0 появилась поддержка SQL"	+/–
	Сообщение от Veter (??), 26-Мрт-10, 12:21
	>Как SQlite организует такую очередь без общего диспетчера ??? Так это задача ОС - первому дать квант времени тому процессу, который дольше всех ждет. Соответственно, именно этот процесс и выполнит очередную блокировку. При желании можно приоритетами процессов поиграться, но обычно в веб-приложениях все процессы равноценные. >> Что касается самих данных, они кэшируются ОС и весьма эффективно - я уже приводил ссылку, где проверяется, что работа с дисковой БД не уступает по скорости операциям с кэшем в ОЗУ. >Похоже в этом и было дело, все очень зависит от типа файловой >системы и организации кеширования в ОС. Насколько я помню FreeBSD кеширует >только мета-данные, видимо в этом и собака порылась. У меня всегда ext3. Кстати, в последних ядрах линукса еще много всего с кэшированием сделали, так что работа с большими базами (намного превосходящими по размеру объем ОЗУ) вроде как должна ускориться.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	30. "В выпуске Berkeley DB 5.0 появилась поддержка SQL"	+/–
	Сообщение от uldus (ok), 26-Мрт-10, 14:07
	>>Как SQlite организует такую очередь без общего диспетчера ??? > >Так это задача ОС - первому дать квант времени тому процессу, который >дольше всех ждет. Это не то, пока заблокировавший базу процесс будет работать с данными планировщик задач успеет миллион раз отдать управление ожидающим освобождения процессам, а потом начнет сразу выполнение следующего запроса и остальные процессы так и будут ждать освобождения лока. Вообще интересно конечно провести экперимент, запустить одновременно два процесса, которые в цикле будут делать UPDATE/INSERT случайных полей и посмотреть насколько равномерным получится распределение. Еще можно к тем двум добавить несколько выполняющих SELECT. Тогда сразу все по полкам разложится, насколько эффективно балансировка обращения к базе в SQLite работает. > Соответственно, именно этот процесс и выполнит очередную блокировку. Получается, что при каждом запросе sqlite открывает и закрывает файл, а при следующем запросе по сути начинает с чистого листа ?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	31. "В выпуске Berkeley DB 5.0 появилась поддержка SQL"	+/–
	Сообщение от Veter (??), 26-Мрт-10, 14:45
	> Получается, что при каждом запросе sqlite открывает и закрывает файл, > а при следующем запросе по сути начинает с чистого листа ? При _подключении_ открывает файл. Если в каждом коннекте только один запрос, то каждый будет "с чистого листа" - если не используется shared cache и встроенный сервер. В вебе использую отдельное подключение на каждый HTTP-запрос - т.к. процессор уровня кореквадро позволяет в секунду инициировать около 8 000 новых подключений к базе, а количество выполняемых HTTP-запросов в разы меньше. Открытие БД занимает несколько сот микросекунд, в зависимости от сложности схемы БД и количества загружаемых расширений. В принципе, главное - использовать короткие транзакции. Например, делая копию выборки в in-memory таблицу (временную), чтобы на этапе отрисовки веб-страницы и прочей обработки результата не блокировать основную БД от записи. Зато скорость выполнения запросов радует: http://geomapx.blogspot.com/2009/11/postgresql-81-vs-sqlite-... Часто получается, что на администрирование нагруженного постгреса больше времени уходит, нежели на написание необходимых расширений к эскулайт.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	32. "В выпуске Berkeley DB 5.0 появилась поддержка SQL"	+/–
	Сообщение от uldus (ok), 26-Мрт-10, 14:55
	>При _подключении_ открывает файл. Если в каждом коннекте только один запрос, то >каждый будет "с чистого листа" - если не используется shared cache >и встроенный сервер. Если открывает при подключении, то и база остается заблокированной на весь сеанс работы или сразу несколько процессов файл с базой на запись открывают и потом координуруют между собой каким-то образом внесение изменений в файл ? >результата не блокировать основную БД от записи. Зато скорость выполнения запросов >радует: >http://geomapx.blogspot.com/2009/11/postgresql-81-vs-sqlite-... В этом тесте тоже измеряются неконкурирующие отдельные запросы. Попробуйте протестировать работу нескольких конкурирующих процессов с активностью на запись данных.
	Ответить \| Правка \| К родителю #31 \| Наверх \| Cообщить модератору


	33. "В выпуске Berkeley DB 5.0 появилась поддержка SQL"	+/–
	Сообщение от Veter (??), 26-Мрт-10, 15:18
	>Если открывает при подключении, то и база остается заблокированной на весь сеанс Нет, с чего бы. Пока мы не начнем модифицирующую транзакцию, никакой блокировки нет, читать можно из любого числа процессов параллельно. Как только один из процессов вносит изменения, выполняется блокировка и все остальные процессы приостанавливаются до окончания транзакции, после чего продолжают выполнять запросы. > В этом тесте тоже измеряются неконкурирующие отдельные запросы. > Попробуйте протестировать работу нескольких > конкурирующих процессов с активностью на запись данных. К примеру: http://geomapx.blogspot.com/2009/11/postgresql-to-sqlite-rep... Для веб-сервера тестировал от 20-ти до 100 одновременных потоков на чтение/запись, но тесты не выкладывал. Были проблемы примерно до версии эскулайт 3.5.9, о чем я уже упоминал, а сейчас все работает как надо.
	Ответить \| Правка \| К родителю #32 \| Наверх \| Cообщить модератору