forum.opennet.ru - "В выпуске Berkeley DB 5.0 появилась поддержка SQL" (34)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

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

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

"В выпуске Berkeley DB 5.0 появилась поддержка SQL"	+/–
Сообщение от opennews on 24-Мрт-10, 21:18
Компания Oracle анонсировала (http://www.oracle.com/us/corporate/press/063695) релиз открытой БД Berkeley DB 5.0 (http://www.oracle.com/database/berkeley-db/db/index.html), ориентированной на эффективное и надежное хранение данных. Berkeley DB выполняется напрямую в использующих данную БД приложениях (встроена в приложение), позволяя программам быстрее выполняться на встраиваемых системах, включая КПК и мобильные устройства. Начиная с данного выпуска в официальном анонсе вместо порядкового номера версии (5.0) теперь фигурирует "Berkeley DB 11g Release 2". Основным улучшением новой версии является поддержка SQL API, позволяющего производить манипуляции с данными не только в классическом представлении ключ/значение, но и в виде совместимом с SQLite. Внимания также заслуживает появление поддержки организации обращения к БД через коннекторы, совместимые со стандартами JDBC и ODBC. Кроме того, проведена адаптация Berkeley DB для мобильной платформы Android, при этом данная БД может выс... URL: http://www.oracle.com/us/corporate/press/063695 Новость: http://www.opennet.dev/opennews/art.shtml?num=25940
Высказать мнение \| Ответить \| Правка \| Cообщить модератору

Оглавление

В выпуске Berkeley DB 5.0 появилась поддержка SQL, gutmann, 21:18 , 24-Мрт-10, (1)

В выпуске Berkeley DB 5.0 появилась поддержка SQL, Аноним, 21:38 , 24-Мрт-10, (2)

В выпуске Berkeley DB 5.0 появилась поддержка SQL, MTTeam, 23:06 , 24-Мрт-10, (3)

В выпуске Berkeley DB 5.0 появилась поддержка SQL, Анонимъ, 00:00 , 25-Мрт-10, (4)

В выпуске Berkeley DB 5.0 появилась поддержка SQL, uldus, 00:20 , 25-Мрт-10, (5)

В выпуске Berkeley DB 5.0 появилась поддержка SQL, Veter, 14:38 , 25-Мрт-10, (15) –1

В выпуске Berkeley DB 5.0 появилась поддержка SQL, szh, 21:39 , 25-Мрт-10, (20)

В выпуске Berkeley DB 5.0 появилась поддержка SQL, Veter, 22:35 , 25-Мрт-10, (23)

В выпуске Berkeley DB 5.0 появилась поддержка SQL, funny_falcon, 19:25 , 02-Июл-10, (34)

В выпуске Berkeley DB 5.0 появилась поддержка SQL, uldus, 22:09 , 25-Мрт-10, (21)

В выпуске Berkeley DB 5.0 появилась поддержка SQL, Veter, 22:25 , 25-Мрт-10, (22)

В выпуске Berkeley DB 5.0 появилась поддержка SQL, uldus, 22:57 , 25-Мрт-10, (24)

В выпуске Berkeley DB 5.0 появилась поддержка SQL, Veter, 23:52 , 25-Мрт-10, (25) –1

В выпуске Berkeley DB 5.0 появилась поддержка SQL, uldus, 11:05 , 26-Мрт-10, (26)

В выпуске Berkeley DB 5.0 появилась поддержка SQL, Veter, 11:54 , 26-Мрт-10, (27)

В выпуске Berkeley DB 5.0 появилась поддержка SQL, uldus, 12:09 , 26-Мрт-10, (28)

В выпуске Berkeley DB 5.0 появилась поддержка SQL, Veter, 12:21 , 26-Мрт-10, (29)

В выпуске Berkeley DB 5.0 появилась поддержка SQL, uldus, 14:07 , 26-Мрт-10, (30)
В выпуске Berkeley DB 5.0 появилась поддержка SQL, Veter, 14:45 , 26-Мрт-10, (31)
В выпуске Berkeley DB 5.0 появилась поддержка SQL, uldus, 14:55 , 26-Мрт-10, (32)
В выпуске Berkeley DB 5.0 появилась поддержка SQL, Veter, 15:18 , 26-Мрт-10, (33)

FireBird-embedded?, Mna, 02:01 , 25-Мрт-10, (6)

FireBird-embedded?, Аноним, 03:09 , 25-Мрт-10, (8) +1

FireBird-embedded?, Аноним, 04:48 , 25-Мрт-10, (9)

FireBird-embedded?, Анонимко, 06:54 , 25-Мрт-10, (10)

FireBird-embedded?, Sokoloff, 10:09 , 25-Мрт-10, (11)
FireBird-embedded?, turbouser, 10:41 , 25-Мрт-10, (12) +1
FireBird-embedded?, Аноним, 19:58 , 25-Мрт-10, (19)

FireBird-embedded?, pro100master, 14:13 , 25-Мрт-10, (14)

FireBird-embedded?, Ы, 16:50 , 25-Мрт-10, (17)

FireBird-embedded?, pro100master, 17:46 , 25-Мрт-10, (18)

В выпуске Berkeley DB 5.0 появилась поддержка SQL, Аноним, 02:44 , 25-Мрт-10, (7) +1

В выпуске Berkeley DB 5.0 появилась поддержка SQL, Аноним, 15:10 , 25-Мрт-10, (16)

В выпуске Berkeley DB 5.0 появилась поддержка SQL, hizel, 11:18 , 25-Мрт-10, (13)

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

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

Сообщение от gutmann on 24-Мрт-10, 21:18

"Сначала добавим туда SQL, а потом, когда почти все пользователи этой БД будут писать запросы через SQL, то можно заменять (хоронить) её на SQLite" - подумал Ларри.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

Сообщение от Аноним (??) on 24-Мрт-10, 21:38

как бы SQLite не пришлось заменять (хоронить). :)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

Сообщение от MTTeam (ok) on 24-Мрт-10, 23:06

Да ну, брось. Живее всех живых

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

Сообщение от Анонимъ on 25-Мрт-10, 00:00

Чем плоха SQLite?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

Сообщение от uldus (ok) on 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 (??) on 25-Мрт-10, 14:38

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

Сообщение от szh (ok) on 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 (??) on 25-Мрт-10, 22:35

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

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

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

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

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

Сообщение от Veter (??) on 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) on 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 (??) on 25-Мрт-10, 23:52

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

Сообщение от uldus (ok) on 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 (??) on 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) on 26-Мрт-10, 12:09

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

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

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

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

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

Сообщение от Veter (??) on 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) on 26-Мрт-10, 14:55

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

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

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

6. "FireBird-embedded?" +/–

Сообщение от Mna (??) on 25-Мрт-10, 02:01

А тогда почему бы не использовать FireBird-embedded?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

8. "FireBird-embedded?" +1 +/–

Сообщение от Аноним (??) on 25-Мрт-10, 03:09

Нииии - дураков нет! Ешьте это сами! :)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

9. "FireBird-embedded?" +/–

Сообщение от Аноним (??) on 25-Мрт-10, 04:48

И чем он так плох? Не флейма ради, просто любопытно. Давно уже ничего не слышал про него, а недавно вот вспомнил... :-)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

10. "FireBird-embedded?" +/–

Сообщение от Анонимко on 25-Мрт-10, 06:54

Требует слишком много внимания к себе.
Недавно я на одном сервере, которому именно firebird нужен, в планировщике перезагрузку сервера закомментировал. Думаю, в течение недели еще успею услышать немного матов на тему скорости работы сервера.
Базу раз в неделю пережимаю и возвращаю на место, после чего перезагружаюсь. Таких СУБД мне не нужно.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

11. "FireBird-embedded?" +/–

Сообщение от Sokoloff on 25-Мрт-10, 10:09

Странно, у меня уже много лет используется firebird, вообще никакого ухода не требует. Работает себе и работает.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

12. "FireBird-embedded?" +1 +/–

Сообщение от turbouser on 25-Мрт-10, 10:41

если база или софт ее использующий кривыми руками спроектирована - нечего пенять на сам firebird

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

19. "FireBird-embedded?" +/–

Сообщение от Аноним (??) on 25-Мрт-10, 19:58

Можно ли узнать, что это за задача, что Достойнейшая Птичка базу за неделю раздувает, и требует внимания администратора?
Описание в студию!

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

14. "FireBird-embedded?" +/–

Сообщение от pro100master (ok) on 25-Мрт-10, 14:13

> И чем он так плох? Не флейма ради, просто любопытно. Давно уже ничего не слышал про него, а недавно вот вспомнил... :-)
плох тем, что не терпит ламеров и не прощает им ошибок. Так же и в оракле.
Работаем с ib/fb/oracle еще с прошлого тысячелетия :)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

17. "FireBird-embedded?" +/–

Сообщение от Ы on 25-Мрт-10, 16:50

Ню-ню - расскажи о вкусе устриц тем кто их и в самом деле ел! :)
Что в Оракле тоже никогда не знаешь восстановится база из отмеченного как успешный из бакапа или нет? Что оракАл вылетает сам от любого чиха? Ну и под конец расскажи что у оракала токое же ... хмм ... скажем оригинальное понимание стандарта SQL?
Дело конечно хозяйское. Но лучше уж MySQL который тоже еще то ГГ - чем FB который в RDBMS есть абсолютное зло и мега ГГ. ____НЕ____ IMHO!

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

18. "FireBird-embedded?" +/–

Сообщение от pro100master (ok) on 25-Мрт-10, 17:46

> Дело конечно хозяйское. Но лучше уж MySQL который тоже еще то ГГ
ну вот, а говорил, что ел. Не знаешь вкуса устриц :) MySQL ___встраиваемый___ это псц и по деньгам, и по стабильности. Плавали.
А летит всё. С Oracle только одно хорошо - это приложение само в себе - т.е. приложение можно сделать (и делаем) полностью рабочим на сервере. А вот общая стоимость владения, особенно на распределенных, заставляет искать варианты.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

Сообщение от Аноним (??) on 25-Мрт-10, 02:44

> Основным улучшением новой версии является поддержка SQL API
Надеюсь эта поддержка отключается при компиляции.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

Сообщение от Аноним (??) on 25-Мрт-10, 15:10

>API
>API
>API
Просто внешний бинарник, предоставляющий интерфейс sql.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

Сообщение от hizel (ok) on 25-Мрт-10, 11:18

у них была какая-та нашлепка которая делала из sql запроса код, видимо теперь все из коропке : )

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

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

Партнёры:

Хостинг:

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

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

1. "В выпуске Berkeley DB 5.0 появилась поддержка SQL"	+/–
Сообщение от gutmann on 24-Мрт-10, 21:18
"Сначала добавим туда SQL, а потом, когда почти все пользователи этой БД будут писать запросы через SQL, то можно заменять (хоронить) её на SQLite" - подумал Ларри.
Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	2. "В выпуске Berkeley DB 5.0 появилась поддержка SQL"	+/–
	Сообщение от Аноним (??) on 24-Мрт-10, 21:38
	как бы SQLite не пришлось заменять (хоронить). :)
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	3. "В выпуске Berkeley DB 5.0 появилась поддержка SQL"	+/–
	Сообщение от MTTeam (ok) on 24-Мрт-10, 23:06
	Да ну, брось. Живее всех живых
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору

4. "В выпуске Berkeley DB 5.0 появилась поддержка SQL"	+/–
Сообщение от Анонимъ on 25-Мрт-10, 00:00
Чем плоха SQLite?
Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


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


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


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


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


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


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


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


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


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


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

6. "FireBird-embedded?"	+/–
Сообщение от Mna (??) on 25-Мрт-10, 02:01
А тогда почему бы не использовать FireBird-embedded?
Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	8. "FireBird-embedded?"	+1 +/–
	Сообщение от Аноним (??) on 25-Мрт-10, 03:09
	Нииии - дураков нет! Ешьте это сами! :)
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	9. "FireBird-embedded?"	+/–
	Сообщение от Аноним (??) on 25-Мрт-10, 04:48
	И чем он так плох? Не флейма ради, просто любопытно. Давно уже ничего не слышал про него, а недавно вот вспомнил... :-)
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	10. "FireBird-embedded?"	+/–
	Сообщение от Анонимко on 25-Мрт-10, 06:54
	Требует слишком много внимания к себе. Недавно я на одном сервере, которому именно firebird нужен, в планировщике перезагрузку сервера закомментировал. Думаю, в течение недели еще успею услышать немного матов на тему скорости работы сервера. Базу раз в неделю пережимаю и возвращаю на место, после чего перезагружаюсь. Таких СУБД мне не нужно.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	11. "FireBird-embedded?"	+/–
	Сообщение от Sokoloff on 25-Мрт-10, 10:09
	Странно, у меня уже много лет используется firebird, вообще никакого ухода не требует. Работает себе и работает.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	12. "FireBird-embedded?"	+1 +/–
	Сообщение от turbouser on 25-Мрт-10, 10:41
	если база или софт ее использующий кривыми руками спроектирована - нечего пенять на сам firebird
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	19. "FireBird-embedded?"	+/–
	Сообщение от Аноним (??) on 25-Мрт-10, 19:58
	Можно ли узнать, что это за задача, что Достойнейшая Птичка базу за неделю раздувает, и требует внимания администратора? Описание в студию!
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	14. "FireBird-embedded?"	+/–
	Сообщение от pro100master (ok) on 25-Мрт-10, 14:13
	> И чем он так плох? Не флейма ради, просто любопытно. Давно уже ничего не слышал про него, а недавно вот вспомнил... :-) плох тем, что не терпит ламеров и не прощает им ошибок. Так же и в оракле. Работаем с ib/fb/oracle еще с прошлого тысячелетия :)
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	17. "FireBird-embedded?"	+/–
	Сообщение от Ы on 25-Мрт-10, 16:50
	Ню-ню - расскажи о вкусе устриц тем кто их и в самом деле ел! :) Что в Оракле тоже никогда не знаешь восстановится база из отмеченного как успешный из бакапа или нет? Что оракАл вылетает сам от любого чиха? Ну и под конец расскажи что у оракала токое же ... хмм ... скажем оригинальное понимание стандарта SQL? Дело конечно хозяйское. Но лучше уж MySQL который тоже еще то ГГ - чем FB который в RDBMS есть абсолютное зло и мега ГГ. ____НЕ____ IMHO!
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору