Pure.....Вот слово "успешно" я бы убрал ...

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

SERG1257
С какой стати? Административные задачи сами собой испарились? Пользователи сами собой завелись с нужными правами, ресурсы (память/диск) сами собой эффективно распределились в зависимости от нагрузки?

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

SERG1257Это просто значит, что для данной задачи дефолтные настройки являются оптимальными.

Что есть в вашем понимании "дефолтовые настройки"? Апстримовская сборка, сборка из моего репозитория, выставляемые приложением параметры? :-) Я говорил про то, что не требуется постоянно настраивать при изменении нагрузки/соотношения типов запросов/объема данных в БД/etc. Пример - при изменении названных величин в постгресе съезжают все планы запросов, что требует периодической перенастройки. Да еще чертов гистерезис при изменении значений параметров.

SERG1257Согласен, только вероятность бага в вашем велосипеде куда выше, чем в фиче взрослой СУБД по причине лучшего тестирования последней

Странное утверждение. Есть понятие полноты тестового покрытия, а "лучшее тестирование" - это вы что, верите в исчерпывающее тестирование методом тыка (вручную)? Например, тест модуля работы с ip-адресами:
http://sqlite.mobigroup.ru/artifact/b0c8fcc099
Вы готовы на основе своих знаний о "взрослых СУБД" предложить свой комплект тестов?..

SallerSERG1257...
Судя по Вашему высказыванию все эти функции сами делаются в продвинутой СУБД, а в простой все надо делать руками админа?

Позвольте я проиллюстрирую ваш вопрос, т.к. он очень даже в тему.

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

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


Если своей головой подумать не хотите, то посмотрите хотя бы, к примеру, зачем оракл использует вспомогательную СУБД (timesten). Будете утверждать, что это решение несуществующих проблем? Или решение проблем, которые запросто можно решить средствами оракл, только его разработчики о том не знают? Хинт: то, что проблема неразрешима средствами самой СУБД, отнюдь не означает неразрешимость в целом.

Vinny the POOH
А row-level security, например, как делать? Для трёхзвенной архитектуры, конечно, не столь важно, но всё же?

Пожалуйста:

The "authorizer" methodThe "authorizer" method provides access to the sqlite3_set_authorizer C/C++ interface. The argument to authorizer is the name of a procedure that is called when SQL statements are being compiled in order to authorize certain operations. The callback procedure takes 5 arguments which describe the operation being coded. If the callback returns the text string "SQLITE_OK", then the operation is allowed. If it returns "SQLITE_IGNORE", then the operation is silently disabled. If the return is "SQLITE_DENY" then the compilation fails with an error.

If the argument is an empty string then the authorizer is disabled. If the argument is omitted, then the current authorizer is returned.

Хоть на уровне ячейки делается проверка доступа.

Vinny the POOH
А куда прикажете кешировать планы запросов, статистику и частоиспользуемые блоки данных? Всецело полагаться на кеш ОС? Он не оптимизирован для этого, нет...

Статистика хранится в системных таблицах, посмотрите тот же постгрес. Планы запросов прекрасно кэшируются на уровне клиентского подключения, глобальный кэш для них не особо полезен. Что касается часто используемых блоков данных то и вовсе - одна из проблем постгреса, в частности, это двойная буфферизация, т.к. постгрес кэширует уже закэшированнные ОС данные. И это проблема почти всех СУБД, исключая разве что оракл на raw device (нет ФС - нет кэша ОС). Так что кэш ОС есть всегда, только СУБД в своем большинстве не умеют им пользоваться. И этот кэш ничуть не хуже кэша СУБД, алгоритмы аналогичные используются (см. lru). Более того, в рэйд-контроллерах есть еще и кэш записи, притом более эффективный, нежели в СУБД и часто используемый совместно с СУБД :-) Это и без рэйд-массива легко проверить - с десктопными дисками 7200 rpm СУБД работает хуже, нежели с чем-то вроде 10 000 rpm raptor, хотя скорость линейного чтения фактически идентична и при идеальном кэшировании и планировании IO в СУБД разницы от более "умного" контроллера диска с большей глубиной очереди быть не должно.

Vinny the POOH
Конечно, для запросов вида SELECT * FROM моя_телефонная_книжка SQLite, атсос или фокспро - вне конкуренции, но для чего-то сложнее - нет. Иначе не было бы "навороченных" СУБД...

Вы пытаетесь доказать логичность и необходимость чего-то самим фактом его существования? Забавно, т.к. это догмат веры, а к логике отношения иметь не может, и обычно выражается как "что боженька пошлет". Задумайтесь хотя бы, сколько различных "навороченных" систем сгинуло за короткий век существования электронной вычислительной техники...

Yo.!
интересно в чем смысл в переносе учитываю нишу и объемы типичной бд sqllite ?

Припоминается мне одна система на эскулайт, состоящая из кластера 10-ти ксеонов с 32 ГБ ОЗУ каждый, на которых крутятся in-memory эскулайт БД как раз размером в эту ОЗУ. Для вашего сведения, московский биллинг сотового оператора большой тройки на оракле хранит около 16 терабайт данных и работает на очень мощном "железе". Так что вот не надо заявлять, что мол БД на треть терабайта это такая мелочь, что не заслуживает внимания. У меня пока не возникало потребностей работать с БД более нескольких десятков Гб размером, хотя тестирую проекты обычно на БД в 10 раз больших, нежели их планируемый рабочий размер. т.е. до сотен Гб.

Yo.!
полезность системной статистики собранной с тестового PIII 500Mhz с IDE дисками на 3GHZ xeon с SCSI...

А кто вас заставляет собирать статистику черт знает откуда? Поставьте идентичную машину или даже на рабочей машинке сгенерируйте.

Yo.!
если речь о статистики таблиц, индексов - то в любой взрослой субд эта статистика собирается автоматом и без вмешательство дба. кстате, в отличие от sqllite взрослая субд имеет сотню механизмов по отслеживанию устаревшей статистики, не говоря уже о отслеживании не оптимальных планов и огромный пласт наворотов вокруг.

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

Yo.!
тайный смысл в переносе 3 байтов "статистики" для типичной sqllite базы в 3Мб думаю для меня останется загадкой.

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

Yo.!огромная проблема куцых субд с небогатым набором методов доступа - вымывание кеша. запрос в sqllite читающий большую таблицу тупо забьет кеш оси одной таблицей со всеми вытекающими...

Про двойную буфферизацию в постгресе не знаете? Любой процесс, читающий данные из ФС, для ОС эквивалентен, независимо от функций, в нем реализованных. А вот "тупо забьет кеш оси" это не так, см. реализацию кэша ФС (по крайней мере, в линуксе, других ОС уже лет пять не видел, ничего о них сказать не могу).

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

Интересно, а что помешает вирусу "дописать свое тело без разбора во все сетевые файлы, в том числе" файлы данных СУБД? Вы открыли закон природы, по которому испортить файлы таблиц постгреса вирусам запрещено? :-) Если нет, то не давайте прямого доступа к файлам, и не будет их модификации, независимо от того, что это за файлы.

Siemargl
Интересно, а как обстоят дела с резервированием?
У кого как. У меня лично - утилита sqlite3-rdiff Для синхронной репликации тоже можно сделать, просто руки не дошли пока, не было надобности.

Siemargl
Кстати sqlite без кэша работать просто не умеет. В этом тесте, если откинуть BEGIN TRANSACTION - sqlite работал два часа (а mssql - 10минут).

Вы разеные режимы смотрите - в эскулайте у вас автокоммит с fsync. Отключите fsync и получите желаемую шустрость.

Siemargl
В том то и разница, что в клиент-сервере прямого доступа к файлам БД нет никогда. И даже с сервера, потомо что открыты эксклюзивно.

Дайте мне рутовый доступ к вашему серверу, и посмотрим, сколько секунд мне понадобится, чтобы прибить все ваши "эксклюзивно открытые" файлы БД.

Yo.!
смешно, какая проверка может быть когда файлы бд торчат наружу (из ФС-сервера) и любой дурачек мимо этого интерфейса поверх файлов бд свой порноархив записать может и это в лучшем случае. в худшем кто-то сообразительней hex-редактором изменит пару строк не оставив никаких следов со всеми вытекающими.
...


У вас веб-интерфейс и прочие сервисы тождественно равняются полному доступу к серверу? Меняйте профессию...

Pure.....MBG
...
Вы готовы на основе своих знаний о "взрослых СУБД" предложить свой комплект тестов?..
Э-эээ, не понял в чем вопрос. Это предложение помериться у кого тесты лучше? :)

Предложение подтвердить свои утверждения доказательствами. Утверждение, что СУБД лучше, потому что она "взрослая" - это детский сад какой-то.

Yo.!MBG
У вас веб-интерфейс и прочие сервисы тождественно равняются полному доступу к серверу? Меняйте профессию...
нет, лично у меня применение фс-субд в 21 веке тождественно умственной неполноценности применяющего, не зависимо какими интерфейсами пытаются прикрыть убогость этой фс-субд. упрятывание фс-субд за трехзвенкой решает некоторые из самых больших недостатков фс-субд, но простота как известно хуже воровства...

Бедный оракл - не посоветовался с вами, покупая файловую СУБД BerkeleyDB, а теперь тратится на ее развитие. А в последней версии еще и движок эскулайта интегрировали для поддержки SQL. Срочно звоните Ларри Эллисону - сообщить, что вы с ним не согласны... Заодно предложите in-memory СУБД TimesTen выкинуть, которую они тоже купили, не посоветовавшись с вами.