Ветка открыта в продолжение дискуссии:
http://www.sql.ru/forum/actualthread.aspx?tid=394935&pg=13

Итак проедемся по пунктам, определимся с терминами. Будем считать единицей информации учетной системы торгового профиля - операции типа приход/расход в кассу, на расчетный счет, приходование/реализация одной позиции тмц многострочного документа, взаимозачеты и т.п. Данные приводятся для компашки с количеством операторов 14 чел.
skeptik
1) Сдается мне Вы несколько преувеличиваете с порядками хотя бы потому, что непонятно, с чем и по какой методике ты сравнивал свою платформу....

За год они умудряются настучать порядка 180-200 тысченз таких операций. 4-5 тысяч товарной номенклатуры, пару сотен контрагентов. Полное перепроведение за год занимает около 600 mс. Пользуюсь привычным Вам термином, так как на самом деле такого явления как отмена проведения и повторное проведение там нет. Перепостроение чем то похоже на работу с стеком. Семерка отстучала примерно такой же год за 12 часов. Отчет по эффективности продаж в 1С-э он называется ABC-анализ - 90 mc против 7 минут
skeptik
2) Ты умалчиваешь чем пришлось заплатить за быстродействие (допускаю что оно существенно выше чем у 1С). Скорее всего, применена метода "засунем все в память". Таких систем я видел не одну (ну хотя бы "ТБ-корпорация" или "Quik"). Проблемы у них обычно начинаются, когда данные "внезапно" начинают не лезть в оперативку (причем, как ни смешно, для многих "потолком" становится 2Гб).

Так и есть, все засунуто в оперативку, включая первичную информацию. Но все в памяти это слишком скромно. Сервер объединяет на одном непаханом поле памяти все что имеет отношение к существованию данных (оперативных и пострасчетных), эти выполнены на объектной основе и собственно алгоритмы их обработки на уровне пользовательских запросов. Уровень клиента это интерфейс с конечным пользователем, диалоги, контроль корректности заполнения полей вводимых/редактируемых данных. Выше упомянутый объем данных, вместе с пострасчетными занимает 30-35 Mbt. Диск используется исключительно как backup, на случай перезагрузки.
skeptik
Еще один интересный вопрос: сколько времени потребуется на холодный рестарт системы (если данных много). Ну и сложности с интеграцией, особенно при экстремиском подходе к этой архитектуре ("стандартную СУБД использовать не будем вааще"). Возможно применена не метода "засунем все в память", а метода "напишем соптимизированную под быстродействие структуру таблиц и соптимизированные запросы к СУБД" (правда тогда выигрыш 3-4 порядков еще менее реален).
На приведенных выше объемах время рестарта 3-4 с. С диска тащит все таки.
e skeptik
В этом случае за быстродействие заплачено проблемами с кадрами, трудоемкостью (и стоимостью) разработки прикладных решений, и в особенности трудоемкостью модификации этих прикладных решений в стиле "чего изволите".

Здесь Вы возможно и частично правы, нашару действительно ничего не бывает. Пару слов по поводу трудоемкости. Весьма спорный вопрос. Вы наверное догадываетесь, с такой реактивностью на приземленных объемах в подавляющих случаях можно не использовать транзакции, а то же перепроведие делать в монопольном режиме, что будет незаметно для операторов. Да и вот упустил, на P-1 230 Mhz перерасчет показывал 60000 оп/с, селик 3 Ghz - 300000, всего в пятеро быстрее. Здесь наверное сказываются ограничения времени доступа к елементам в памяти, скорость проца уже не сильно сказывается. Надо как нить попробоваться на 64-разрядной шине.
Пока все.

PerftorgeksanЕсли вы такой любитель реактивных скоростей, то может проще базу для 1С разместить на виртуальном жестком диске (то есть в оперативке)? Тогда у вас 1С-ка тоже летать будет. А вот про то что транзакции не нужны - это прогонка, они нужны всегда. Их нужность сразу понимаешь при первом же падении системы с потерей данных. Сравнение перепроведения с "псевдоперепроведением" некорректно. А 12 часов на перепроведение документов за год... в принципе приемлемое время, если документов огромное количество, но я с такими базами не сталкивался. Я встречал базы где перепроведение за год выполняется примерно за час-полчаса, и это считалось нормальным временем.
Ну для кого я изголялся целых пол часа. 1С работает с элементами расположенными в таблицах, таблицы расположенны в файлах, достукиваться нужно ч/з третьи руки. Все это против полей объекта , которые априори в памяти, рядом с кодом ими манипулирующими. Отсутствие транзакций чревато нерегистрацией последней операции и все.
12 часов было получено на селике 1.7, думаю здесь все честно. :)

skeptikИзвинясь, за проблемы с цитированием. Исправленный вариант:
Вообще-то это не очень большие объемы. Так что вопрос что делать будете когда оперативка кончится (тем более, что обычная программа на C++/Дельфи ограничена адресным пространством 2 Гб) остается актуальным.
Да, не очень показательные объемы, но интерполировать вы же умеете.
skeptik
?! какой метод расчету учетных цен Вы используете? А партионный учет, серийные номера и т.п. есть?
Метод списания средневзвешенные цены. Вы хотите меня убедить, что партионный учет это преимущество, а не навязанная необходимость структуры 1С. Скажу так, отчетность может быть представлена в том виде, как будто списание шло по принципам FIFO/LIFO. Вот серийных номеров действительно нет. В свою бытность постановщика учета, как то не сложилась потребность знать на каком серийном номере телевизора сколько заработано или какие серийные номера у видаков за которые Вася Пупкин не расплатился. Это задачи сервисных служб. Вы оправдываете наличие такой функции общей спячки системы финансового контроля - ваше право.
skeptikА можно попадробнее. Не исключено, что Вы что-то новое для меня придумали.
Можно, токи быстро не получится.
skeptik
что-то больно мало. 150 байт на позицию документа вместе с пострасчетными данными ...

Почему мало? Парочка корреспондентов - несколько индексов, четыре суммы мультивалютной операции, еще пару десятков байт на вспомогательные мелочи. Это же чистые данные без всякой шелухи. Ну и собсно накопительные регистры они объем добавляют раз в месяц
skeptik
Так с диска или из СУБД? Если сбросить что-то близкое к дампу занятой памяти на диск, то 3-4 секунды еще можно представить чтение, но из с субд, запросами, да плюс выделение памяти, построение и заполнение структур. Что-то больно быстро.
Диск и СУБД это неразделимые понятия? Вы че нить про сериализацию объектов в потоки информации слышали? Им все равно куда течь. В файл, клиенту, обратно серверу, другому удаленному серверу.
skeptikТ.е. вообще транзакции не используете?
Используем, на уровне достаточном для мнгновенного поднятия системы после форсмажорной ситуации
skeptik
В общем предварительные(!) выводы:
1) Очень простенький (скорее даже примитивный) и весьма стабильный при том учет.
2) Скромные объемы данных и число одновременно работающих.
3) Надежность и достоверность данных не критична.
4) "Жесткий код" предельно соптимизированный именно под данный учет и данные объемы.

Оптом: Стабильный учет это когда в прошлое не лазят(не соответствует, лазят очень активно)
Малые объемы данных, см. начало ответов. Надежность и достоверность пунк требований № 1, добавьте сюда еще и прозрачность, как гарантию достоверности. Код жесткий для конечного пользователя, соптимизирован под данный учет, но не под объемы. Последнее все пральна. Это иструмент конечного пользователя учета, а не наш с вами.

MX -- ALEX
Напишите пожалуйста про Вашу систему подробнее
Спасибо
Наша система унаследована от пионера учетных систем 90-ых. "Финансы без проблем". Платформа незаслужена подзабыта, данные по ее эксплуатации в свое время отличаются от наших теперешних максимум 5-7 раз. В основном конечно, за счет постояных оптимизаций. Загляните к ним, там много чего есть за стоки лет.

gybsonЯ скажу только то, что 1С сбалансирована не вокруг скорости, и меня это устраивает. Моих клиентов тоже. На мой взгля, эффективную учетную систему баллансировать вокруг скорости работы нельзя.

Да не расматривайте вы реактивность системы как самоцель. Прежде всего это переход количества в качество. Давайте по пунктам
1. Это возможность не заботиться об актуальности после вмешательство в прошлое.
1.а Не навязывать сторнирования, так как это атавизм бумажной, журнально-ордерной системы, а мы вроде чего то автоматизировать взялись.
2. Возможность формирования отчетности небольшими порциями, вместо выкладывания простыней в скролируемую область экрана. Ну да, основное время это сканирования базы данных, посему сканируем как можно реже, а оправдываем это длиной простыни на экране.
3. Отсутствие необходимости тщательного прицеливания перед подачей запроса на отчет. Здесь параметр поменял, получи в новом разрезе.
4. Куча вспомогательных параметров для операторов-манагеров, типа кто резервировал, что ждем, по какой цене данному покупателю отпускалься данный товар последний раз. Данные об этом нигде не готовятся. Каждый список группы тмц несет их без принуждения. Да, при этом он сканирует последние три месяца деятельтности. Это 7-9 mc.
5. Ну собсно и сам баланс на любой момент времени в прошлом и настоящем, пол-секунды с регулярным равенством пассива и актива.
Ну в общем Вы меня поняли, скорость это не повод запрещать курить персоналу, а потенциальная возможность совершенствовать функционал. Последнего как извесно много в принципе небывает :)

Еще упустил, для компашки на 4-6 пользователя хватает пентиума 1. Более мощной машины они не смогут оценить. А в наше время это 20 доллорей на барахолке.

skeptik
Это как, расчет себестоимости по ФИФО в процессе построения самого отчета?

Да не очень сложно, задачка ведь формализуется. Строится поштучная цепочка поступлений, потом на нее накладывается поштучное списание. Со спичками наверное может быть не быстро. :)
skeptik
...серий лекарств и тому подобных милых вещах характерных имено для системы финконтроля слышали?
Вот с настоящими партиями, которые нужно отслеживать не из соображений правильности списания, а из потребности вовремя продать, вернуть, выкинуть, с автоматикой проблема. Здесь должна быть предоставлена возможность исключительно ручного выбора партий, исходя из соображений доступных самому оператору. Говоря другими словами автоматическое списание по алгоритму не катит, т.к. в этом случае при изменениях задним числом условия списания могут изменится, что не будет соответствовать реально произошедшим событиям. Я не жадный, этим не занимаюсь, бум считать это одним из существенных недостатков систем с автоактуализацией как таковых.
skeptik
А где хранятся с шелухой?
Наверное правильно сказать нигде. Шелуха к данным прилагается в момент ее востребования. Любой набор информации имеющий тип всегда может быть воспроизведен в предустановленном контексте.
skeptik
А что будет если у Вас файл с сериализованными объектами запорется потому как в момент записи питание вылетит, напаример? Мне было интересно узнать сколько занием подьем сервера с нуля, из "данных с шелухой".
Да ничего катострофического не будет. Вы подзабыли как работает файловая система. До момента записи старый файл перименовывается, новый создается из потока, после удачной транзакции, копия хоронится. Сервер поднимается с нуля за пяток секунд, в данных нет шелухи. Кистати тот объем занимает на диске в развернутом состоянии менее 10 метров.
skeptik
То расказывали, как здорово Вы экономите на отсутсвии транзакций, то говорите что они есть. Давайте уточнять где они есть и для чего именно используются (а где соответственно нет).
Где используются, а где нет попробуйте определить самостоятельно исходя из следующих соображений:
1. Данные могут потеряться, исказиться, только в результате форсмажорных обстоятельств.
2. Для предотвращения таках обстоятельств используются синхронизация и блокировки.
3. Ну а ежли свет пропадет и UPS окажется дохлым в неподходящий момент, можно подняться с нуля за пять сек.
4. Сервер нигде и никогда не хранит пострасчетную информацию в перманентном виде
skeptik
...Это батенька читерство. В таких условиях можно и 1С разогнать на пару-тройку порядков :-)

На условия при которых 1С можно разогнать отвечаю цитатами на выбор.
"Это что, этак и я могу, а вот ты Мурку?" или "А я угадаю эту мелодию с трех нот, .. Угадывай"

Александр Федоренко Uncle_Alex
Метод списания средневзвешенные цены. Вы хотите меня убедить, что партионный учет это преимущество, а не навязанная необходимость структуры 1С.


А как вы с ГТД собираетесь разбираться без партионного учета?

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

gybsonКажется пошло очередное сравнение кабриолета с белазом. Если копнем еще дальше окажется, что супербыстрая система не покрывает и 10% функционала типовой конфигурации 1С, а дописывать этот функционал тяжко и особо некому, потому система и работает с лохматого года.

Некоторые и на Бэсте под дос до сих пор работают. Разница в тех, кто с этим работает, тетки под 50 (еще немного и на пенсию) или молодые люди в костюмах, которым еще ой как много надо заработать.

О каком функционале речь, о том самом где к понятию баланс прикладывается понятие отчетный период. Или тот где штатными средствами в мультивалютном исполнении можно положить в кассу 1 рубль и стать весомее на $10000. Ну вот тетки бухгалтерши это точно не к мне. Мой контингент как раз те самые, которые налоги платить не любят, но и своего упускать не желают.

И на послед. В мои намерения не входило перекрыть все и вся, я попытался показать, что новым может оказаться давно позабытое старое. Сервер "Финансов без проблем", мы им пользовались еще пару лет тому назад делался когда 64 метра памяти считалось круто. Ща я имею задел если не на сотню то на полтинник пользователей. Зачем рогом упираться, в то что заведомо имеет существенные проблемы. Система срелизена даже не на плюсах, просто java. Не самое медленное средство разработки и поддержки.