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 тож ничо, но естественно помедленнее.
И то и другое для телекома самое то.