Уважаемые господа специалисты в базах данных, теоретики и практики!

Очень интересует ваше мнение о строении БД, особенности которой описаны вот здесь

Эта база используется в фреймворке, который был разработан для решения учетных задач (бухгалтерия). Внедрений у нее совсем не много, около пары сотен. Но они есть и исправно работают уже много лет. При этом наиболее крупное внедрение - это завод численностью около 2000 человек. Штат бухгалтеров (и, соответственно кол-во рабочих мест во внедренном комплексе) - 30.

При этом сие чудо показывает чудеса производительности именно прикладных задач, а именно: рассчет зарплаты на всю эту толпу в 2000 человек - 2 минуты, оборотная ведомость за год - тоже около 2-х минут. Это самые тяжелые рассчеты. Остальное просто незаметны. При том что остальные бухгалтера продолжают работать и никакой просадки в производительности на себе не ощущают. Те, кто работал с тем же самым 1C могут поделиться своими впечатлениями о работе системы с таким кол-вом пользователей и времени рассчета зарплаты с таким кол-вом человек.
Возникают вопросы: как и почему?

Я провела интервью с разработчиками комплекса и получила информацию о строении БД, которая собственно в статье и описана. Хотелось бы узнать мнение специалистов, особенно тех, кто занимался разработкой или работал с учетными системами с одной стороны, и тех, кто глубоко знает теорию БД и обладает хорошими именно практическими навыками. Как вам вообще такой подход? Есть в нем что-то или как?

Со своей стороны - я постараюсь узнавать у разработчиков и отвечать на любые возникшие вопросы, если в чем-то потребуется детализация.

Dimitry Sibiryakov,

В основном потому что в этом топике обсуждаются совершенно разные базы. И еще потому что предлагается сравнить сие творение с другими СУБД, но не конкретными наименованиями, а скорее, классами баз. Я пытаюсь плюсы/минусы понять.

Yo.!,

Но вы ведь имеем факт: 30 машин для бухгалтерского прикладного ПО в сети, все это прекрасно себе живет и умирать совершенно не собирается.
Я с вами согласна в контексте того, что если туда к примеру несколько сотен клиентов посадить, оно наверно захлебнется. Я как раз хочу найти возможность провести эксперимент именно на эту тему - посмотреть какое максимальное кол-во одновременных пользователей такая штука сможет выдержать.

Второй момент, касается задач, на которые ориентирована СУБД. Сейчас в мире приходит понимание того, что классический реляционный подход не всегда идет на пользу решаемых задач, посему начали придумывать всяческие отхождения от стандарта: in-memory, с поколоночным хранением, вообще объектно-ориентированные. Раз они существуют, значит это кому-нибудь нужно?
Здесь то же самое. Эта базка конечно во многом слабее, чем классический клиент-сервер. Но есть ощущение, что она гибче, и легче позволяет решать некоторые задачи. В основном учетные: когда у вас не много пользователей (30 бухгалтеров - это и правда много) и при этом довольно много всевозможных сложных рассчетов. А структуры данных приходится строить такие, что черт ногу сломит.
Вот где-то здесь она и начинает играть, по моим ощущениям.

К примеру, насколько я понимаю ситуацию, за счет того, что у них нет жесткого описания структуры атрибутов в таблице, они создают одну таблицу, к примеру, для каталога товаров, и пихают в нее все что только душе заблогарассудится: колбаса, значит колбаса, автомобиль, значит автомобиль. И никих вам EAV и наследуемых таблиц... В итоге, максимальное кол-во таблиц которое им приходилось решать для конкретной учетной задачи - 200. Обычно гораздо меньше. В других подобных системах, как я понимаю, они считаются тысячами.

locky,

Это довольно очевидный аргумент :) Понятно что дыр в ней потенциально должно быть больше, чем у других СУБД именно по тем причинам, которые вы описали. Но я сейчас не рассматриваю возможность построения системы на ней, - я пытаюсь понять перспективность такого подхода к организации хранения и обработки данных в принципе. Может я ее развивать хочу :) ну или не я :)

.ЛПYo.!кстати, есть вопрос. если "централь" рассылает в широковещательном режиме, как она убеждается, что все клиенты получили обновление ? в сети может быть кратковременный сбой и некоторые клиенты могут не получить обновление.
Этот вопрос очень, очень интересен.
Особенно в свете декларируемого "в случае потери сервера, сервером можно объявить любую из рабочих станций"

как это вообще - "потеря сервера"?
шел по улице, никого не трогал, пиво пил, и тут - ВНЕЗАПНО - сервер где-то потерял...
бида, бида, огорчение...
По номеру транзакции. Если станция получила обновление с пропуском, она запрашивает у сервера недостающее и тогда он уже ей персонально пересылает.

.ЛПкак это вообще - "потеря сервера"?
Здесь имеется в виду - вышел из строя. Сгорел например, или что-то еще такое произошло...
Тогда просто выбирается какая-нибудь станция (ручками, не автоматом) и у нее взводится флажек, - что она теперь сервер. И можно жить дальше.

.ЛПВ базе хранится вся история, от ишачьей пасхи до сегодняшнего дня. Вся эта база в полном объёме находится у всех клиентов.
На самом деле, не совсем так. У них там есть механизм - называется компрессирование. Он как раз и предназначен для того, чтобы "схлопнуть" историю. Я так понимаю, что время от времени они этим пользуются. У всех клиентов хранится - да. Но объемы-то смешные получаются. Прирост на самых больших внедрениях около 200MB в год... Кстати тоже не понимаю за счет чего. По идее - при полной записи истории она пухнуть должна быстрее, но этого не происходит.

.ЛПВсе клиенты на каждый чих и пук бродкастят уведомления. И наверное как-то их обрабатывают. Для всего набора данных. Все изменения. Нужно, не нужно, пофигу.

Не клиент бродкастит, а сервер. Клиент передает данные на сервер уже не бродкастом а конкретно ему. И не на каждый чих. Данные передаются только об изменениях.
А что вы имеете в виду под "нужно, не нужно, пофигу?"

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

Ммм.. да. Скорее всего. Так и не позиционируется это для больших нагрузок на запись.

.ЛПЕй богу, уж лучше взять обычное файл-серверное нечто. Фокспро. Аксес.
У Аксес я так понимаю все-таки проблемы с многопользовательностью? Или нет?

.ЛПНа обычном файл-серверном нечте сваять этот несчастный расчёт зарплаты.
Для тридцати пользователей, обрабатывающих по чуть-чуть данных аж о двух тысячах каких-то там зарплат - оно будет летать ничуть не хуже.
Эххх... узнать бы у кого кто на этом самом файл-серверном нечте уже нечто такое сваял и сравнить результаты... :) Это и правда интересно. Кстати фреймворк в целом у меня вызывает ощущение чего-то похожего на Access именно, интерфейс только более топорный, но это поправимо имхо. А так, - тоже рисуются таблички и формочки для ввода + встроенный язык для обработки. По словам разработчиков очень развитый, поддерживающий ООП в полном объеме, и еще много чего.

.ЛПДаже на де-факто умершем файл-серверном нечте.
А вот с этим я кстати не согласна. Тот же Access используется очень широко. И как раз для случаев когда в офисе нужно быстро сваять что-то учетное очень малыми силами и при почти полном отсутствии знаний/образования/ресурсов

.ЛПХотя обратно непонятно, чего бы не сделать и на любой нормальной СУБД. Коих как грязи.

.... Вот поэтому и "не сделать на нормальной СУБД".

.ЛПТо, что жопорукие адынэсовцы сумели сделать долго и медленно - это ещё не повод, чтоб вот такое вот изобретать.

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

Cane Cat FisherПо поводу формата хранения, и разруливания блокировок, эту систему можно назвать "версионник, возведенный в абсолют", со всеми достоинствами и недостатками.

Версионник - да, похоже. А можно поподробнее о недостатках?

Cane Cat FisherНо практика показала, что чаще всего требования эти растут. И проблемой является именно задача расширения систем "в разы". Поэтому и придумали SQL-сервера - они масштабируются легче, позволяют накрыть более широкий диапазон задач - от быстрого (ну, в разумных пределах :) сбора телеметрии, до огромных неторопливых хранилищ аналитики.

Частично с вами соглашусь, но сегодня все-таки начинает наблюдаться и обратная тенденция: начали выплывать альтернативные стандартным реляционным базам решения. Я об этом уже говорила выше.

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

Согласна в контексте "под каждую отдельную задачу". Но вот если попытаться выделить классы задач?

Cane Cat FisherПоэтому, я бы предположил, что в таком неторопливом режиме, на 30 бухгалтеров, можно было бы сделать систему практически на любой платформе. Аналогичные задачи - вариантную структуру записей, и т.д. - решить другими, но вполне работоспособными способами. А если те же усилия, что пошли на разработку своей системы, пустить на оптимизацию системы на SQL - результат был бы ничуть не хуже, а, уверен, лучше, и главное - перспективнее.
Вообще, я бы посоветовал, сейчас не прикручивать к этому делу SQL, а срочно перевести этот фреймворк (за который авторам честь и хвала), на работу с нормальным SQL - сервером.

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

У них, к примеру, есть такой режим песочницы. Он используется и бухгалтерами и при отладке комплекса. Если перевести станцию в локальный режим работы, то вам в теории ничего не мешает начать кромсать данные в базе как вам заблогарассудится - типа - эксперименты проводить. Вы можете этим часами заниматься. А потом просто сказать что-то типа undo и система у вас вернется в начальное состояние. В теории - так же просто делать и пошаговый undo и на заданный момент времени. Как вот эту, например фичу реализовать в стандартном реляционнике, вот без такого потокового метода записи - я не представляю, - накладные расходы слишком большими будут.

Насчет переноса на стандартный SQL-сервер. У них связь реализована. Т.е. есть API для цепляния и к обычному серверу. Но для реализации прикладных задач они этим не пользуются - говорят неудобно. Используют связку только если интеграция нужна.

Edd.Dragon,
Спасибо конечно, но я не разработчик :) Просто разработчики - мои очень близкие знакомые и я несколько лет так или иначе слушала про их систему всякие байки. Сейчас есть шанс все это раскрутить более серьезно. Вот я и оцениваю перспективы.

Vladimir Baskakov,
Так летает уже. Только в предыдущей версии, которая по некоторым характеристикам морально устарела, но база там именно такая как описана. А в предыдущей версии полный учет предприятия - как в 1C. В новой пока только зарплата.

Vladimir Baskakov,
Нет, там не стартап. Контора работает с 90х годов и обслуживается силами ээ... 2.5 программистов (в разные годы по-разному, но среднее число примерно такое). При этом они всех своих клиентов успевают поддерживать и вовремся выпускать все изменения в законодательстве, которые за эти годы имели место быть. Говорят что все это благодаря только гибкости фреймворка.

Gluk (Kazan)интересующаяся_мнениемУ них, к примеру, есть такой режим песочницы. Он используется и бухгалтерами и при отладке комплекса. Если перевести станцию в локальный режим работы, то вам в теории ничего не мешает начать кромсать данные в базе как вам заблогарассудится - типа - эксперименты проводить. Вы можете этим часами заниматься. А потом просто сказать что-то типа undo и система у вас вернется в начальное состояние. В теории - так же просто делать и пошаговый undo и на заданный момент времени. Как вот эту, например фичу реализовать в стандартном реляционнике, вот без такого потокового метода записи - я не представляю, - накладные расходы слишком большими будут.

Как то так ?
Да, по эффекту примерно похоже. Нууу... Oracle наверно может все, но это очень дорого, и по стоимости и по обслуживанию. Согласитесь.. небольшая конторка вообще без админов его себе позволить не может.

Gluk (Kazan)То есть 200 внедрений это НЕ серьезно?
Смотря с чем сравнивать :) Если с 1С например, то эта капля даже не в море, в океане.

SergSuperинтересующаяся_мнением, если Вы собираетесь приобретать такую систему или что-то разрабатывать на ее основе - даже не думайте
причины на поверхности и даже не вижу смысла обсуждать

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

Взять к примеру, переменное число полей в таблицах. Де-факто получается, что у них просто очень широкие таблицы, в которые напихано сразу все. В теории, - ну что мешает сделать это в реляционной СУБД? Тем более что ALTER TABLE, насколько я понимаю, операция простая и в современных СУБД ресурсов не требует особо, а значения с NULL память не забивают.. Так почему не делают? Некошерно? Некрасиво? Почему?

С вычислениями агрегатов на лету, - опять то же самое. Я понимаю, что в теории ничто не мешает в современной БД повесить всю эту обработку на триггера. Но почему-то тоже особо не делают. Почему?

А жаль что не видите смысла обсуждать причины, но воля ваша.

Dimitry Sibiryakovинтересующаяся_мнениемПо номеру транзакции. Если станция получила обновление с пропуском, она запрашивает у
сервера недостающее и тогда он уже ей персонально пересылает.

Такое возможно в двух случаях:
1) Транзакции полностью сериализованы и идут исключительно последовательно;
2) Хранится индивидуальный список принятых транзакций.

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

Какой случай реализован в Вашей системе?

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

Vladimir BaskakovА, тогда хороших полетов! То есть кадры, зарплата, склад, управленка? Налоги всякие... а отпуска, больничные... перекрывающиеся... бюджетирование...

В предыдущей версии - да.

Vladimir Baskakov(тихо, почти шепотом) толстый клиент, да? чур меня, чур меня...

Да, собственно на базе фреймворка и сделан. Клиентские БД, которые в описании базы описаны встроены в фреймворк, т.е. они как встроенная база работают.

Vladimir BaskakovА на чем оно написано? Апи какое?

База и фреймворк написаны на C++, причем чистом, без использования библиотек. Разработчики собирали их детище под разными платформами, не Win - работает. Думаю, полное тестирование все-таки выявит особенности, но опять-таки, думаю, что допилить в случае чего будет несложно.
Сама прикладная часть написана на встроенном языке фреймворка, на нем и API, если дописать что-то хотите. Встроенный язык с полной поддержкой ООП и плюс чего-то там еще умеет. Но в этом мне еще отдельно разбираться надо.

Vladimir BaskakovНапример, я хочу прикрутить к этому мегачуду эксель. Люблю экселевские сводные таблички например... так получилось. Или люблю фаст-репорт. Или кристалл - репорт. Или еще какую нить всеядную фигню...

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

Vladimir BaskakovМой вердикт такой - или - это мегагениальный суперпродукт будущего.... или.... Ну - я романтик - буду верить в хорошее!
Вот и я пытаюсь понять кто я.. или романтик или :) Поэтому и хочу коллективного мнения и критики подхода. :)
Только аргументированной.

Dimitry SibiryakovТ.е. пока с сервером работает один клиент, остальные сидят и курят в очереди.

Почему? Каждый клиент ведь работает со своими локальными данными. Чтение - это вообще не проблема. Обновление записи, - что в такой схеме помешает нескольким клиентам одновременно обновлять данные? Они обновили, - отправили на сервер. А там уже транзакции номер присвоился. Так на практике и происходит.

Dimitry SibiryakovЕщё вопрос:
она продолжает работать с состоянием, актуальным на момент завершения седьмой
транзакции и продолжает формировать данные для следующей. Если она в этот момент завершит
свою работу и изменившиеся данные пойдут на сервер, он не сможет записать ее данные и
сообщит на станцию об ошибке (вспомним, что они редактировали один и тот же документ).
Как сервер определит, что они редактировали один и тот же документ?

Сценарий:
1. Операционистки 1 и 2 начинают редактировать Документ 1;
2. Операционистка 3 начинает редактировать Документ 2;
3. Операционистка 1 сохраняет Документ 1;
4. Операционистка 3 сохраняет Документ 2;
5. Операционистка 2 сохраняет Документ1.
Что делает сервер чтобы сообщить Операционистке 2 об ошибке?

Сервер всегда знает станцию, от которорой пришел запрос на обновление данных.
Допустим в вашем сценарии на начальный момент времени у нас 7 транзакций. Данные от операционистки 2 сервер сохранит в качестве транзакции под номером 8, а от операционистки 3 - 9. Когда придет запрос от операционистки 2, там будет указано, что она хочет сохранить документ 1 и ее последняя транзакция - 7. Сервер увидит, что после этой транзакции уже происходило редактирование этого документа (сохранено в транзакции 8) и он вернет клиенту сообщение об ошибке - что-то вроде "конфликт обновление записи, обновите документ и отредактируйте его снова". Вообще- это задача прикладного программиста отработать эту ошибку. Реакция с точки зрения пользователя может быть и другой, например - перезаписать автоматом, или сравнить запись по полям, обновив автоматом те поля где нет конфликта и дать пользователю решать, как именно разрулить конфликт с конкретным полем, ну и т.п.

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

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

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

Dimitry SibiryakovТо бишь в примере из статьи при записи транзакции 10 надо определить, что транзакция 8
изменила именно Документ 1, а не Документ 3, например.

Ну а как вы в обычной базе определяете, что это уже существующая запись? По ключу. А поиск - индексы.

Yo.!просто совсем без блокировок на некоторых задачах процент неудачных транзакций зашкалит за все разумное.

Согласна полностью. Поэтому для себя я изначально ограничиваю класс задач, для которых данная архитектура применима. Никто и не говорит что это универсальное решение.
Насчет неудачных транзакций, - мне вот еще такая идея приходила в голову: у нас же клиент видит все обновления в локальной базе. В теории, если мы в этой архитектуре проектируем систему, которая предполагает большое количество апдейтов, то нам ничего не мешает чекать обновление и подсовывать их операционистке пока она ворон считает. Т.е. действовать, так сказать, превентивным методом. Это должно сократить неудачные транзакции на стороне сервера. Но тоже до определенного предела конечно. Думаю, сотню операционисток у нас есть шанс обработать, а вот систему, автоматом гонящую потоки данных откуда-то, конечно уже нет.

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