https://www.opennet.me/openforum/vsluhforumID3/65119.html Компания 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".<br><br><br>Основным улучшением новой версии является поддержка SQL API, позволяющего производить манипуляции с данными не только в классическом представлении ключ/значение, но и в виде совместимом с SQLite. Внимания также заслуживает появление поддержки организации обращения к БД через коннекторы, совместимые со стандартами JDBC и ODBC. Кроме того, проведена адаптация Berkeley DB для мобильной платформы Android, при этом данная БД может выс...<br><br>URL: http://www.ora https://www.opennet.me/openforum/vsluhforumID3/65119.html#34 Fri, 02 Jul 2010 15:25:05 GMT я тестировал. <br>Простой тест:<br> скрипт (тогда на питоне) вставляющий строки в таблицу без пауз в транзакции по 50-100 штук<br> две - три консоли<br> запускаешь во всех консолях скрипт<br> ловишь ошибки доступа к файлу, таймауты и прочее<br><br>Второй тест:<br> малюсенькое приложеньеце, грабящее reddit.com<br> малюсенькая вебморда для поиска по награбленному (с паджинацией)<br> тормоза физически ощутимы<br> seige -b (или ab - кому как нравится) - 10req/seq<br> после переключения на Postgresql заметно ускорилось<br> https://www.opennet.me/openforum/vsluhforumID3/65119.html#33 Fri, 26 Mar 2010 12:18:59 GMT &gt;Если открывает при подключении, то и база остается заблокированной на весь сеанс <br><br>Нет, с чего бы. Пока мы не начнем модифицирующую транзакцию, никакой блокировки нет, читать можно из любого числа процессов параллельно. Как только один из процессов вносит изменения, выполняется блокировка и все остальные процессы приостанавливаются до окончания транзакции, после чего продолжают выполнять запросы.<br><br>&gt; В этом тесте тоже измеряются неконкурирующие отдельные запросы. <br>&gt; Попробуйте протестировать работу нескольких <br>&gt; конкурирующих процессов с активностью на запись данных. <br><br>К примеру:<br>http://geomapx.blogspot.com/2009/11/postgresql-to-sqlite-replication.html<br><br>Для веб-сервера тестировал от 20-ти до 100 одновременных потоков на чтение/запись, но тесты не выкладывал. Были проблемы примерно до версии эскулайт 3.5.9, о чем я уже упоминал, а сейчас все работает как надо.<br><br><br> https://www.opennet.me/openforum/vsluhforumID3/65119.html#32 Fri, 26 Mar 2010 11:55:10 GMT &gt;При _подключении_ открывает файл. Если в каждом коннекте только один запрос, то <br>&gt;каждый будет "с чистого листа" - если не используется shared cache <br>&gt;и встроенный сервер. <br><br>Если открывает при подключении, то и база остается заблокированной на весь сеанс работы или сразу несколько процессов файл с базой на запись открывают и потом координуруют между собой каким-то образом внесение изменений в файл ?<br><br>&gt;результата не блокировать основную БД от записи. Зато скорость выполнения запросов <br>&gt;радует: <br>&gt;http://geomapx.blogspot.com/2009/11/postgresql-81-vs-sqlite-3620-in-real.html <br><br>В этом тесте тоже измеряются неконкурирующие отдельные запросы. Попробуйте протестировать работу нескольких конкурирующих процессов с активностью на запись данных.<br><br> https://www.opennet.me/openforum/vsluhforumID3/65119.html#31 Fri, 26 Mar 2010 11:45:09 GMT &gt; Получается, что при каждом запросе sqlite открывает и закрывает файл,<br>&gt; а при следующем запросе по сути начинает с чистого листа ?<br><br>При _подключении_ открывает файл. Если в каждом коннекте только один запрос, то каждый будет "с чистого листа" - если не используется shared cache и встроенный сервер.<br><br>В вебе использую отдельное подключение на каждый HTTP-запрос - т.к. процессор уровня кореквадро<br>позволяет в секунду инициировать около 8 000 новых подключений к базе, а количество выполняемых HTTP-запросов в разы меньше. Открытие БД занимает несколько сот микросекунд, в зависимости от сложности схемы БД и количества загружаемых расширений.<br><br>В принципе, главное - использовать короткие транзакции. Например, делая копию выборки в in-memory таблицу (временную), чтобы на этапе отрисовки веб-страницы и прочей обработки результата не блокировать основную БД от записи. Зато скорость выполнения запросов радует:<br>http://geomapx.blogspot.com/2009/11/postgresql-81-vs-sqlite-3620-in-real.html<br><br>Часто получается, что https://www.opennet.me/openforum/vsluhforumID3/65119.html#30 Fri, 26 Mar 2010 11:07:02 GMT &gt;&gt;Как SQlite организует такую очередь без общего диспетчера ???<br>&gt;<br>&gt;Так это задача ОС - первому дать квант времени тому процессу, который <br>&gt;дольше всех ждет. <br><br>Это не то, пока заблокировавший базу процесс будет работать с данными планировщик задач успеет миллион раз отдать управление ожидающим освобождения процессам, а потом начнет сразу выполнение следующего запроса и остальные процессы так и будут ждать освобождения лока. <br><br>Вообще интересно конечно провести экперимент, запустить одновременно два процесса, которые в цикле будут делать UPDATE/INSERT случайных полей и посмотреть насколько равномерным получится распределение. Еще можно к тем двум добавить несколько выполняющих SELECT. Тогда сразу все по полкам разложится, насколько эффективно балансировка обращения к базе в SQLite работает.<br><br>&gt; Соответственно, именно этот процесс и выполнит очередную блокировку. <br><br>Получается, что при каждом запросе sqlite открывает и закрывает файл, а при следующем запросе по сути начинает с чистого листа ?<br><br><br><br> https://www.opennet.me/openforum/vsluhforumID3/65119.html#29 Fri, 26 Mar 2010 09:21:20 GMT &gt;Как SQlite организует такую очередь без общего диспетчера ???<br><br>Так это задача ОС - первому дать квант времени тому процессу, который дольше всех ждет. Соответственно, именно этот процесс и выполнит очередную блокировку. При желании можно приоритетами процессов поиграться, но обычно в веб-приложениях все процессы равноценные.<br><br>&gt;&gt; Что касается самих данных, они кэшируются ОС и весьма эффективно - я уже приводил ссылку, где проверяется, что работа с дисковой БД не уступает по скорости операциям с кэшем в ОЗУ.<br>&gt;Похоже в этом и было дело, все очень зависит от типа файловой <br>&gt;системы и организации кеширования в ОС. Насколько я помню FreeBSD кеширует <br>&gt;только мета-данные, видимо в этом и собака порылась. <br><br>У меня всегда ext3. Кстати, в последних ядрах линукса еще много всего с кэшированием сделали, так что работа с большими базами (намного превосходящими по размеру объем ОЗУ) вроде как должна ускориться.<br> https://www.opennet.me/openforum/vsluhforumID3/65119.html#28 Fri, 26 Mar 2010 09:09:41 GMT &gt;между ними "вклиниться" нельзя. Иначе запросы выполняются в порядке их поступления <br>&gt;в очередь. <br><br>Как SQlite организует такую очередь без общего диспетчера ??? Программы 1 и 2 прилинкованы к библиотеке, которая при каждом их запуске может судить только о глобальном локе базы (пока файл не будет разлочен, sqlite в нем ничего не сможет поменять), там же нет отдельного хранилища для очереди запросов и для каждого процесса получается своя очередь ?<br><br>&gt; Что касается самих данных, они кэшируются ОС и весьма эффективно - я уже приводил ссылку, где проверяется, что работа с дисковой БД не уступает по скорости операциям с кэшем в ОЗУ.<br><br>Похоже в этом и было дело, все очень зависит от типа файловой системы и организации кеширования в ОС. Насколько я помню FreeBSD кеширует только мета-данные, видимо в этом и собака порылась.<br> https://www.opennet.me/openforum/vsluhforumID3/65119.html#27 Fri, 26 Mar 2010 08:54:30 GMT &gt; Я вам про реальные приложения, а вы мне про синтетические тесты.<br><br>Еще раз - реальные приложения - мои веб-системы с тучей конкурентных юзеров.<br><br>&gt; Поставьте RT, посадите писать тикеты нескольких пользователей - вот вам и тест.<br><br>У эскулайта есть собственная распределенная система управления исходниками - fossil. Там же есть и тикеты и вики. Работает на оффсайте эскулайта, в том числе. И вот почему-то мне ни разу не приходилось ждать несколько секунд, добавляя тикеты, даже когда анонимное добавление было разрешено и этих тикетов море добавлялось.<br><br>&gt; Процесс 1 делает серию последовательных апдейтов базы A, <br>&gt; процесс 2 чуть опоздав делает апдейт базы B.<br><br>Есть понятие транзакционности. Если изменения идут в рамках одной транзакции, то, естественно, между ними "вклиниться" нельзя. Иначе запросы выполняются в порядке их поступления в очередь.<br><br>&gt; Если процесс 2 тоже интенсивно пишет в базу, не получится ли ситуация <br>&gt; вечного перечитывания базы с диска при каждом запросе ?<br><br>Зачем всю базу-то читать? Для https://www.opennet.me/openforum/vsluhforumID3/65119.html#26 Fri, 26 Mar 2010 08:05:13 GMT &gt;&gt; Про deadlock в sqlite я уже не раз слышал. ...<br>&gt;<br>&gt;Улыбнуло. Где тесты? <br><br>Я вам про реальные приложения, а вы мне про синтетические тесты. Поставьте RT, посадите писать тикеты нескольких пользователей - вот вам и тест.<br><br>&gt;Про "однопользовательские системы", наверное, описка. Или 1000 конкурирующих процессов одного пользователя не <br><br>В SQLite не может быть конкурирующих запросов по определению, в каждый момент времени только один процесс всегда имеет доступ к файлу с базой и данные между процессами не расшариваются и не кешируются. Остальные ждут своей очереди, если процесс агрессивно работает с базой, все остальные курят и ждут, пример - RT.<br><br><br>&gt;В жестком диске одна головка пишет в один поток - делаете ли <br>&gt;вывод, что удел жестких дисков - однозадачные системы? <br><br>В СУБД подобных MySQL работает диспетчеризация запросов, при обработке текущего запроса есть картина об очереди запросов в целом и данные могут кешироваться в памяти, запросы обслуживаются одновременно. В SQLite такой диспетчеризации нет, к