Оцените проект: "сервер бухгалтерии"
Цель данного поста: узнать ваше мнение. К тому же, вполне возможно, проект вскоре перейдет в разряд open-source.
Читать этот пост, я думаю, имеет смысл только тем, кто хотя бы поверхностно знаком с бухгалтерией, бухгалтерскими итогами, проведением документов, а еще лучше - с 1С.
Собственно идея.
Есть распространенные бизнес-приложения, предназначенные для бухгалтерского, управленческого и иного, более специализированного, учета. Однако этот софт платный. Есть приложения подешевле - 1С, к примеру, но тот принципиально не поддерживает распределенное хранение и обработку данных. Другие - я не знаю, возможно поддерживают, но они на порядки дороже.
Наш директор считает :) что многим выгоднее купить лишнюю машину под сервер, чем покупать очень дорогое ПО, поскольку серьезное ПО дороже даже нескольких машин. Поэтому
ПЕРВАЯ ЧАСТЬ ИДЕИ такова: делаем так называемый "сервер бухгалтерских итогов", куда приходят клиентские запросы на проведение документов. Сервер распределяет запросы на множество баз данных. Множество БД построено таким образом, чтобы:
1) Ускорить чтение данных;
2) Ускорить запись данных;
3) Повысить надежность системы.
Ускорение чтения и повышение надежности достигается за счет "зеркального" хранения данных: одни и те же данные пишутся параллельно на несколько БД.
Ускорение записи достигается за счет того, что часть данных записывается на один сервер, часть - на другой, т. е., попросту говоря, если документ создает 50 проводок, и имеется 10 баз данных, 5 проводок пишем на одну БД, 5 проводок - на вторую, и т. д.
Итак, получаем "сверхкластерную" архитектуру, в которой имеется N кластеров (кластеры между собой "зеркальны", т. е. содержат одну и ту же информацию), внутри каждого кластера имеется M баз данных (каждая БД содержит часть информации кластера).
Первая часть идеи обеспечивает распределенную и параллельную обработку и хранение бухгалтерской информации.
ВТОРАЯ ЧАСТЬ ИДЕИ: всегда поддерживать актуальность последовательности, т. е. при изменении данных и перепроведении "задним числом" автоматически перепроводить зависимые документы. Соответствующие алгоритмы и структуры данных (и таблиц БД) хорошо продуманы и предусматривают хорошую оптимизацию, которая минимизирует количество перепроводимых данных при восстановлении последовательности и позволяет перепроводить документы частично параллельно, несмотря на то, что имеет место строго хронологическая последовательность, причем эти алгоритмы практически не зависят от алгоритмов проведения каждого документа.
"Эта обитель нелюдей превращает человека в монстра." (с) Если есть возможность, меняй работу.
Да, скорей всего постановка задачи была "никакой". Так как создавали группу КИС для постановки задачи из людей, которые к программированию не имеют никакого отношения, более того, так как этих людей выводили из подразделений (например, из бухгалтерии), то руководство отдавало не грамотных специалистов, а тех от кого хотело избавиться.
Проект до сих пор вылизывается. Жена вчера со счастливой улыбкой сообщила что ежедневный отчет готовившийся по 40 минут стал готовиться 2 минуты (ее счастью не было придела). КИСовци сказали, что поменяли концепцию. (Это спустя полтора года)
ПСЫ Я ей тоже говорю чтоб уходила, но у нас же как? "Пока жилы не все вытянули, и кровь не всю выпили - будем горбатится"
Я тоже когда-то имел счастье наблюдать подобный эффект оптимизации структуры БД и алгоритмов обработки. Софтина на Клариоше создавала отчёт больше суток, после оптимизации тот же отчёт выдавался за 40 секнуд. Оптимизировал не я, а "специально обученный человек". ;)
Мастер делал. Это ж как надо было оптимизировать?
Это же как надо было писать?
Вообще самая злая вычислительная задача, с которой я сталкивался - это просчёт в Terragen сцены с относительно высоким разрешением. Комп считал всю ночь. Но тут я понимаю - графика. А вот отчёт на сутки - этого я понять не могу. Очень охота посмотреть исходники процедуры этого отчёта.
Посмотришь, зачитаешся. Каждый день такие читаю.
Насчет обсуждаемого проекта - за 3 года поддержки информационной системы немаленького (порядка 3000 сотрудников) предприятия сложилось четкое мнение - любая специализированная БД "выдыхаеться" через год-полтора наполнения ее оперативными данными ибо как правило ее создатели не утруждали себя мыслями о быстродействии и объеме хранимых и обрабатываемых данных. Оценить производительность проекта на любой базе данных невозможно не вводя его в эсплуатацию на реальном предприятии, которое кроме "абстрактного генератора данных" представляет собой жесткую ИТ инфраструктуру в условиях существования которой, ему придесться существовать. В свете всего этого высказывания топикастера о том что ему не придеться общаться с клиентами, а только поставлять готовые модули, автоматически переводят проект в разряд мертвых.
Всё просто: грамотная нормализация таблиц, построение нужных индексов (точнее, ключей -- Кларион всё-таки) и соответствующая переделка алгоритма (SQL'а в Clarion 2 DOS нет, посему все выборки строим ручками).
Ну что я могу сказать... Вот такой программист-стройбатовец писал.
Писал не я.
Да и важность патчей не надо возводить в абсолют.
Знаю два положительных примера специальных БД, которые не выдыхаются при большом наполнении: IBM/Lotus Domino версии 5 и выше (если можно назвать документно-ориентированные СУБД специальными) и "Консультант Плюс". Но, конечно, этот софт создавался не по принципу "Лишь бы работало, к осени всё будет готово".
К сожалению не работал с ними. Но если то что говоришь правда, то очень жаль.