Gluk (Kazan)
Знаешь, моих заказчиков *nix-ы в ступор вгоняют (они вообще фанаты дотнету), а ты мне про эрланговые надстройки над BDB

Имхо, сейчас все ИТ-подразделения умеют обращаться с юниксом/линуксом и солярисом. Хотя мне тут сложно оценивать - большинство людей из моего круга общения пользуются линуксом как на работе, так и дома, а статистика почему-то показывает преобладание виндоус :-) Эрланг кроссплатформенный, кстати.

Что касается СУБД без поддержки SQL, на практике выходит, что хранение в них сериализованных многомерных структур данных и распаковка/запаковка их на уровне приложения на существенно "просаживают" производительность, так что эффективнее пользоваться SQL и наборами функций по обработке blob-полей согласно специфике приложения. В какую базу дампать на диск in-memory структуры, так это и вовсе вопрос религии, например, эскулайт имеет отличный тиклевский биндинг (в отличии от берклидб, к примеру) и позволяет легко писать пользовательские функции на С. Собственно, эскулайт в дефолтной поставке это лишь минимальный движок, к которому следует дописать нужную функциональность.

Gluk (Kazan)Про эрланг знаю, было даже у начальства желание пощупать моими руками мнезию, но как то заглохло


Не очень давно mnesia unlimited вышла, там ограничения на объем данных в узле поснимали, красота. В апстрим собирались включить, но не смотрел, включили или еще нет.

Gluk (Kazan)
Ну BDB прямо скажем не особенно просаживает, с учетом того, что OLTP запросы то как правило не особо сложные. Хранится структура и все дела. Кроме того ключ до 2G это сильно.


Это смотря где - в документообороте, к примеру, при прохождении документом очередной инстанции идет проверка всего документа на валидность плюс генерация информации для отчетов. Большой ключ на практике мало интересен - при извлечении десятка тысяч документов при построении отчета какой объем данных надо будет поднять с таким ключом? :-) В реальном времени, скажем прямо, немыслимо делать подобный анализ.

Gluk (Kazan)
Ч учетом того, что BDB не SQL-БД, биндинг звучит несколько загадочно

Биндинг можно к любой динамической библиотеке сделать :-) Свои функции дописать тоже никто не мешает, но уж больно много кода получается для berkeleydb для выборок (понятно, что эмулировать sql-запросы сишным кодом не самая лучшая затея).

PPA MBG[quot Gluk (Kazan)]Кроме того, в эскулайте можно выбрать режим persist, в котором этот файл не удаляется. .

режим persist пока очень сырой (недавно появился).
я получил из-за него существенную просадку производительности на простых select-ах
с индексом по BLOB полю.

В документации же ясно сказано, что этот режим следет использовать на платформах, где операция удаления файла намного более затратная, нежели забивание первого блока файла нулями. Если на вашей платформе это не так, то режим persist вам не подходит.

"The PERSIST journaling mode is useful as an optimization on platforms where deleting a file is much more expensive than overwriting the first block of a file with zeros."

P.S. "Если ничего больше не помогает, прочтите наконец документацию!" (с)

Gluk (Kazan) MBGЭто смотря где - в документообороте, к примеру, при прохождении документом очередной инстанции идет проверка всего документа на валидность плюс генерация информации для отчетов.


Я еще недостаточно спятил, чтобы писать документооборот на BDB :)


На клиент-серверных СУБД пара тысяч одновременных пользователей уже требуют офигенного железа. Плюс указанным СУБД необходим постоянный мониторинг и настройка, которые для необслуживаемых серверов отсутствуют (клиенту устанавливается и настраивается железо+софт и дальше все должно годами работать, пока железо не сдохнет, бэкапы забираются по сети с помощью rsync, к примеру).

Gluk (Kazan)
MBG
Биндинг можно к любой динамической библиотеке сделать :-) Свои функции дописать тоже никто не мешает, но уж больно много кода получается для berkeleydb для выборок (понятно, что эмулировать sql-запросы сишным кодом не самая лучшая затея).

Я под биндингом понимаю параметризованные SQL-запросы

Имеется в виду интерфейс определенного языка программирования к динамической библиотеке.

Gluk (Kazan) MBGНа клиент-серверных СУБД пара тысяч одновременных пользователей уже требуют офигенного железа.


MTS-а они требуют на Oracle


Стоимость лицензий на оракл + стоимость железа + стоимость администрирования ... или нахрена попу наган, если поп не хулиган :-) К тому же оракл имхо неоптимально с железом работает (сотню пользователей мог бы и на целероне обслуживать), и расширяемость так себе - по отзывам, база на десяток терабайт требует очень дорогого железа (если постгрес, кажется, в яху, работает с петабайтными базами, то оракл должен уметь сильно поболее, за свою-то цену). Понятно, что оракл делает упор не на производительность, а на "фичастость" - встроенных возможностей вагон и маленькая тележка, плюс модули... Но все эти возможности в одном проекте не нужны, а требуемую часть из них можно найти/написать.

Полтысячи одновременных пользователей документооборота постгрес+эскулайт обслуживают на пентиум Д с парой гиг памяти, и то я полагаю это немного и можно поднять производительность до нескольких тысяч пользователей на указанном железе.

Gluk (Kazan) MBGСтоимость лицензий на оракл + стоимость железа + стоимость администрирования ...


Для телекома как правило не критична

До поры до времени - при появлении необхпенькеодимости перенести на кластер из десятка средних серверов вместо одного мощного возникает ощущение присутствия в фильме ужасов :-)

Gluk (Kazan)
по поводу производительности: может быть как и SQLite требует более высокого профессионализма чем SQLite ?

Требует мало того что знания оракла, так еще и существенного времени на администрирование. В последние годы набирают популярность необслуживаемые системы, где или все задается на этапе разработки или система автоподстраивается. Боюсь, написать скрипт, который заменит профессионального админа оракл будет непросто... и стоить этот скрипт будет в разы больше самой системы :-)

На самом деле мы обсуждали только движок - эскулайт, на практике к нему добавляют мощный сервер приложений, и вот уже на этой платформе можно разрабатывать достаточно крупные системы. Любую СУБД с ораклом сравнивать сложно, т.к. это уже не столько база данных, сколько сервер приложений и основную ценность представляет именно как мощная платформа с интегрированной СУБД.

BIONВопрос к MBG] : а как в sqlite дело обстоит с многопоточным доступом(не многопользовательским) в масштабах одного приложения, в частности insert? Какова вероятность возникновения ошибок?

Многопоточный доступ работает как в пределах одного приложения, так и при доступе из разных приложений. Если необходимо выполнять модификацию данных из нескольких потоков, удобно указывать таймаут, в пределах которого запрос стоит в очереди и ожидает освобождения блокировки. Ошибки какого рода имеются в виду? Если речь о возникновении коллизий, то это решается созданием очереди запросов (все делает сама библиотека эскулайт, требуется только максимально допустимое время ожидания в очереди указать). Если в работе самой библиотеки, то вероятность повреждения данных очень мала, лично мне такого видеть не приходилось (использую эскулайт уже лет пять как на серверах и КПК). Хотя при многопоточной работе эскулайт с использованием shared cache пользовательское приложение при неправильной работе с потоками имеет возможность повредить базу (по умолчанию эта опция выключена, имхо выигрыш в производительности от ее использования стоит возможного риска только при критической нехватке ресурсов и тщательно вылизанном коде многопоточного приложения). В рассылке эскулайт время от времени появляются пользователи, в режиме shared cache повредившие базу в многопоточном приложении.

При многопользовательском доступе разумно создавать in-memory базу для выполнения длительных операций и к ней монтировать основную базу приложения (для аналитических приложений бывает необходимо создавать отдельную базу на диске для каждого пользователя - когда пользователей сотни и более и каждый может строить отчеты, обрабатывающие многие десятки или сотни мегабайт данных, притом пользоваться однажды созданными отчетами многократно).

Для контроля доступа используется callback-функция autorizer - позволяет для каждого соединения к базе разрешить/запретить определенные операции, например, для потока, выполняющего аудит изменений, разрешить только чтение данных.

PPA MBG
В документации же ясно сказано, что этот режим следет использовать на платформах, где операция удаления файла намного более затратная, нежели забивание первого блока файла нулями. Если на вашей платформе это не так, то режим persist вам не подходит.

"The PERSIST journaling mode is useful as an optimization on platforms where deleting a file is much more expensive than overwriting the first block of a file with zeros."

P.S. "Если ничего больше не помогает, прочтите наконец документацию!" (с)

Журнал используется при выполнении операции select? (у меня БД не модифицируется)

Не используется, но создаваться может - по команде "begin exclusive;" создается файл журнала и база блокируется монопольно. Интересно только, зачем вам понадобилось для операций чтения эксклюзивную блокировку ставить?..

PPA MBG
Не используется, но создаваться может - по команде "begin exclusive;" создается файл журнала и база блокируется монопольно. Интересно только, зачем вам понадобилось для операций чтения эксклюзивную блокировку ставить?..

У меня явной блокировки нет.

Проблема вообще выглядит так
после указания прагмы PRAGMA journal_mode=PERSIST;

Скорость выполнения нескольких десятков тысяч запросов вида
select count(*) from fly_tth where tth=?;
уменьшается в 10-ки раз

убираешь прагму - все становится хорошо.

версия - свежачек 3.6.1 :)

Сколько транзакций используете? Ну и тест выкладывайте.

PPA MBG
Сколько транзакций используете? Ну и тест выкладывайте.

В данном месте вообще не используются транзакции
я не меняю данные - выполняется серия select-ов.

история проблемы тут:
http://forum.wafl.ru/index.php?showtopic=5179&pid=79228&st=0entry79228

diff исправления такой:
http://code.google.com/p/flylinkdc/source/detail?r=387#

т.е. удаление "PRAGMA journal_mode=PERSIST;" решило проблему

после PERSIST тормозят такие вызовы
CFlylinkDBManager::is_old_tth(const TTHValue& p_tth)
CFlylinkDBManager::is_download_tth(const TTHValue& p_tth)


Если транзакция не стартует, то указанная прагма ничего не меняет, это можете посмотреть в исходниках эскулайта.

Как пример, пара моих тестовых скриптов (версия SQLite 3.5.9):
Вот скрипт создания базы размером 25365K:

А вот скрипт для чтения

Время выполнения последнего примерно 25 секунд и при удалении обсуждаемой прагмы не меняется.

Проблема в вашем враппере. Функция is_old_tth вызывает функцию get_tth_id, в которой создается транзакция и в ней выполняются операции insert. Посмотрите, во время выполнения запросов рядом с файлом вашей базы появляется файл журнала.