MBG White OwlПлюнь в того кто тебе это посоветовал.
SQLite это встраиваемая база. Для микро задач. Вот недельную-месячную историю продаж на ней хранить запросто. Запихнуть ее в кассовый терминал для хранения чеков - идеально.
Заменять ею большую базу - идиотизм.

SQLite на средних базах данных (до 100 гиг) отлично себе работает. В биллинге необходимо разделить данные по месяцам и при построении отчетов attach-ть нужные базы. Ну, если у вас за месяц набегает более 100 гиг данных, придется еще что-то придумать.

P.S. Сказанное относится к ФС ext3 и грамотно настроенной базе. Про fat, ntfs и прочие поделия ничего сказать не могу.

Угу угу. Только вот SQLite (по крайней мере та версия шо я гонял) создает по файлу на каждую транзакцию. Создает и удаляет, создает и удаляет Ну и для кучи, БД на любой DML блокирувается ексклюзивна :) Забавно будет посмотреть ЭТО в биллинге.

Про GigaBase врать не буду, но еенная сестренка FastDB тоже очень смешная :)

MBGИ чем вам этот файл так не нравится?


Да в общем-то всем нравится :) только при частой фиксации транзакций (что для биллинга характерно), постоянное создание/удаление файла просаживает производительность на столько, что SQLite в основном занимается только этим Производительность падает на порядки.
Можно конечно сделать транзакции подлинее, но тогда в полный рост втсает второй фактор ;)

MBG
Операционная система, веб-сервер и, к примеру, постгрес тоже много чего создают и удаляют,


Дык СУБД тем и отличается от файловой системы, что старается эти вещи оптимизировать. А фиксация транзакций - бутылочное горло для любой известной мне РСУБД :(
Например Oracle ничего не создает и не удаляет, а перезаписывает поверх старого REDO. И уж разумеется не занимается маразмом с созданием удалением файла на каждом commit-е
Кстати, а чего там Postgress постоянно создает/удаляет ? Удивите меня

MBG
просто вы об этом не догадываетесь.


ага ;)

MBG
В последнем вот только недавно проматывание счетчика транзакций на читающих транзакциях устранили.


В SQLite ? А Вы твердо уверены, что сие есть Бобро, а не уродливый костыль ???

MBG
Кроме того, в эскулайте можно выбрать режим persist, в котором этот файл не удаляется. Не нужна вам целостность базы при аварийном отключении сервера - можете вообще отказаться от использования файла журнала, в скорости существенно выиграете.


Ага, конечно. Зачем нам целостность та ?
Вот persist конечно несколько более умно, надо посмотреть на досуге

MBG
Блокировка базы имеет свои преимущества - на SATA-дисках много эффективнее записывать на диск в одном процессе, так что эскулайт на таких дисках дает очень высокую производительность.


И свои недостатки :) Два DML не могут выполняться одновременно
Т.е. все DML-и выстраиваются в очередь. Для производительности исключительно полезно

MBG
Версионные СУБД на SATA при сотне-другой транзакций в секунду упираются в производительность дисков. Эскулайт, при полной блокировке базы, в единицу времени больше транзакций выполняет.


Проводили тестирование ? С чем сравнивали ? Oracle, Postgress, IB, MS SQL 2005 ???
С небольшим приложением в виде результатов тестирования, заявление звучало бы менее голословно ;)
Кстати, дабы исключить влияние механизмов версионности, возможно разумнее сравнивать блокировочники с блокировочниками ???

MBG
И зачем вам DML в больших количествах в биллинге - может, просто термин нравится? :-)


Ага, нравится :) Только ими можно сказать и занимаюсь
Очень интересно, посмотреть на биллинг БЕЗ insert-ов и update-ов
Кстати, под биллингом я имею в виду Internet. Телефонный тоже можно, если он поддеживает prepaid

MBG
Кстати, на многоядерных серверах эскулайт линейно масштабируется - если вам это о чем-то говорит.


Как только чем нибудь подкрепите свои слова, сразу же скажет.
Не в первый раз уж слышу сказки про линейную масштабируемость, да только видеть ее никогда не доводилось :(
Кстати, количество процессоров далеко не самый главный фактор в производительности СУБД

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


Да Вы шо o O
Может просто сравним цифры ???

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

Не скрою (с) к нулевому администрированию SQLite ближе чем Oracle
Если бы она еще и работатала ...

Собственно я не хочу сказать, что SQLite это плохо. У нее есть своя ниша (Web, CD-справочники), но биллинг ?

Как я уже говорил выше, я не считаю SQLite "плохой" СУБД. Более того,
я считаю ее лучшей в классе встраиваемых СУБД, поддерживающих SQL и
поставляемых в открытых исходных кодах. Речь, таким образом идет о том,
что она могла бы быть (и вероятно будет) ГОРАЗДО лучше, если избавится
от некоторых детских болезней (разумеется все сказанное исключительно IMHO).
Ниже приводятся данные о производительности SQLite в зависимости от частоты
фиксации транзакций (исходные тексты теста прилагаются)


Столь существенное снижение производительности (почти в 300 раз), вызвано
ИСКЛЮЧИТЕЛЬНО неудачным (и легко исправляемым) архитектурным решением -
ведением отдельного (не особенно при том лаконичного) ФАЙЛА журнала
на каждую выполняемую транзакцию. Отговорки на тему дешевизны операций
создания/удаления файла в *nix-системах не выглядят убедительными, когда
речь идет о СУБД, одним из достоинств которой является кроссплатформенность.
Когда речь заходит об относительно легко устраняемом архитектурном дефекте,
советы поставить "правильную" операционную систему (а при невозможности этого,
отказаться от целостности данных) выглядят несколько странно.
Кроме того, сколь бы не дешева была операция, она никак не дешевле чем ее
НЕ выполнение. Зачем тратить время на то, чего делать не нужно ???
Ни одна из известных мне СУБД (включая упоминавшийся здесь Postgress) не
занимается созданием/удалением файлов в рамках выполнения фиксации/отката
транзакции. Думаю, что глупо спорить с тем, что ничем не оправданная идея
сделать бутылочное горло записи REDO еще более узким исключительно НЕУДАЧНА.

Ситуация с монопольным блокированием БД при выполнении DML, разумеется менее
однозначна. Более того, для Embedded БД такое решение более чем разумно.
Действительно, зачем тратить ресурсы на блокировки уровня строк, если БД
используется в однопользовательском режиме? Такие СУБД как TimesTen например,
поддерживают режимы монопольного блокирования БД не только при выполнении DML,
но и на время ЛЮБОЙ незавершенной транзакции (в том числе состоящей только из
операций чтения). Но это именно режимы, а не единственно возможное поведение.
И эти режимы практически непригодны для многопользовательской работы (клановые
мантры о необходимости гораздо большей квалификации при работе с SQLite чем
при работе с Oracle, прошу также оставить в стороне. ЛЮБАЯ работа требует
высокой квалификации и профессионализма).
Другой причиной неудобства этого режима (не очень существенной для Embedded,
но вполне весомой для OLTP) является теоретическая невозможность горизонтального
масштабирования (увеличением количества потоков) БД, работающей в таком режиме.
Для меня было приятным сюрпризом узнать, что TimesTen (к примеру), в рамках
разумного количества потоков (до 10) масштабируется вполне линейно (разумеется
не столь ощутимо как Oracle). Разумеется, TimesTen СОВЕРШЕННО не масштабируется
в режиме монопольного блокирования БД :)
Пикантность ситуации с SQLite добавляет то, что по всей видимости (помимо прочего)
необходимость монопольного блокирования БД, при выполнении DML напрямую связана
с пионерским (в смысле передовым конечно ;) ) решением ведения отдельного файла
на каждую транзакцию. Впрочем, это всего лишь моя теория.

Таким образом, я не веду речь о том, достаточна или нет производительность SQLite
для некоего сферического биллингового приложения (хотя и считаю, что с учетом
озвученных ранее цифр совершенно недостаточна для средненького Internet-биллинга
или биллинга сотовой телефонии). Биллинг биллингу рознь, и почему бы не использовать
SQLite в биллинге проводной телефонии, с оказанием исключительно postpaid-услуг?
Разумеется, зайди речь о выборе для такого применения SQLite vs Gigabase, мои
предпочтения (по ряду причин) оказались бы на стороне первой.
Но ее производительность могла бы быть еще лучше. И кому от этого было бы плохо?

P.S. Кстати, как связано устранение проматывания счетчика в Postgress с созданием/удалением файлов ?

MBG
...
правильные системы, правильные компиляторы, сакральные знания + с потолка взятые 50000


Все как обычно

MBGВыбран тест, не зависящий от жесткого диска, впрочем, результаты в одной транзакции для базы на диске практически идентичны.


Ясен перец :) а теперь сделай транзакции поменьше, чтобы на OLTP было похоже, а не на заливку CDR-а ;)

MBG
Насчет компилятора - результаты теста должны быть воспроизводимы. GCC позволяет воспроизвести тест на любой другой машине, вижуал среды - нет. Причины я объяснил в предыдущем посте.

Насчет файловой системы - знать особенности используемой ФС полезно, а иногда и необходимо. Я пользуюсь ext3 и учитываю ее особенности. Если вы не знаете, как работает ваша ФС, это ваши проблемы. Если вы не знаете размер кластера вашей ФС, то у вас почти любая СУБД будет работать неэффективно.

Постом ранее я вам привел набор полезных для повышения эффективности работы базы директив с пояснениями. Если вы хотите разобраться, то попробуете сами. Если нет - не отнимайте время у себя и других людей.

Все это прекрасно и замечательно, но передо мной ставилась задача определить кто из Embedded/IMDB быстрее на Windows из под MSVC :)
Задача выбора правильной ОС не стояла.
Есть мысли, что улучшить в МОЕМ коде, чтобы работала пошустрее на Windows ?

P.S. Кстати BDB с TimesTen сделали SQLite как стоячую

И еще, ДРУГ, мне надоели твои намеки на мои знания/незнания особенностей работы FS, Postgress и т.п. Будь проще

MBGЕсли не хотите менять или настраивать ОС и ФС, то остальное зависит больше от архитектуры приложения, тут уж вам должно быть виднее.

Ну то есть фактически: RAID и persist (+ prepared)
Как я и думал. На Windows не вариант

MBG Grami Gluk (Kazan)P.S. Кстати BDB с TimesTen сделали SQLite как стоячую

TimesTen делает как стоячих и Oracle и MSSQL :) Другое дело, что область применения у TimesTen существенно уже.

TimesTen это что-то вроде berkeleydb? Тогда уж tokyocabinet смотрите, там на ноуте выходит более миллиона вставок в секунду. Только это совершенно другой класс СУБД. А berkeleydb еще и администрирования требует, что для встраиваемого решения не есть хорошо.

TimesTen - IMDB. Очень шустрая, но платная. Не Embedded, крутится отдельным сервисом. Очень продуманная, кроссплатформенная. BDB тож ничо, но естественно помедленнее.
И то и другое для телекома самое то.

MBGДля телекома скорее уж mnesia хороша, для того она и создана :-) Но и она кстати для дискового хранения использует берклидб, токиокабинет или эскулайт. Как вариант, использую in-memory hash для хранения очень часто изменяемых данных, а при старте/останове сервера читаю/пишу их в эскулайт базу. Впрочем, это имеет смысл, если одновременно работающих пользователей около полутысячи и более, иначе не стоит и заморачиваться.

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

GramiTimesTen делает как стоячих и Oracle и MSSQL

А какая из них Embedded или IMDB ? ;)

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


Честно ? Спим и видим как перейти на разработку под никсы, но кто девушку кушает, тот ее и танцует :( Про эрланг знаю, было даже у начальства желание пощупать моими руками мнезию, но как то заглохло

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


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

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

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

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


Гмм. а зачем забивать блок нулями ?

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


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

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

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

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


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

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

ну это вообще мелочи

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


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

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

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

поставь 8 Oracle на Linux и получай удовольствие на том-же пеньке