Здравствуйте, Яndex HR, Вы писали:

ЯH>- опыт промышленной разработки на C++ не менее 3 лет
ЯH>- опыт использования STL (STLPort будет плюсом)
ЯH>- знание Oracle на уровне разработчика (SQL, PL/SQL)
ЯH>- опыт использования CORBA (OmniORB будет плюсом)

Н-да... IMHO: при таком архитектурном раскладе проект ничем хорошим не кончится.
Сугубо субъективное мнение (предостережение) возможным кандидатам.

Здравствуйте, EXO, Вы писали:

EXO>Здравствуйте, Яndex HR, Вы писали:

ЯH>>- опыт промышленной разработки на C++ не менее 3 лет
ЯH>>- опыт использования STL (STLPort будет плюсом)
ЯH>>- знание Oracle на уровне разработчика (SQL, PL/SQL)
ЯH>>- опыт использования CORBA (OmniORB будет плюсом)

EXO>Н-да... IMHO: при таком архитектурном раскладе проект ничем хорошим не кончится.
EXO>Сугубо субъективное мнение (предостережение) возможным кандидатам.

А на чем основывается мнение?
Вроде вполне нормальная мультиплатформенная связка.

Здравствуйте, Аноним, Вы писали:

ЯH>>>- опыт промышленной разработки на C++ не менее 3 лет
ЯH>>>- опыт использования STL (STLPort будет плюсом)
ЯH>>>- знание Oracle на уровне разработчика (SQL, PL/SQL)
ЯH>>>- опыт использования CORBA (OmniORB будет плюсом)

EXO>>Н-да... IMHO: при таком архитектурном раскладе проект ничем хорошим не кончится.
EXO>>Сугубо субъективное мнение (предостережение) возможным кандидатам.

А>А на чем основывается мнение?
А>Вроде вполне нормальная мультиплатформенная связка.

Для информации: такая платформенная связка в Яндекс работает уже 5 лет, и выдерживает такие нагрузки, которыми почти никто в России больше похвастаться не может.

Здравствуйте, Anatolix, Вы писали:
А>>А на чем основывается мнение?
А>>Вроде вполне нормальная мультиплатформенная связка.

A>Для информации: такая платформенная связка в Яндекс работает уже 5 лет, и выдерживает такие нагрузки, которыми почти никто в России больше похвастаться не может.

(Кстати привет )
Да знаю я, что она может работать хорошо, если будет написана по уму. Только обойдется такое в наше время очень дорого (раньше "время" было другое — в смысле его было больше). Такую архитектуру нельзя "выдать быстро", а оно наверняка потребуется... в резултате — выйдет абы как.

Смотрим по порядку:
"- опыт промышленной разработки на C++ не менее 3 лет"
сразу не быстрый вариант по времени разработки... и для плюсов, 3 года не бох весть какой опыт — только-только начинаешь понимать что к чему.
Кстати, биллинг предполагает не столько расчеты, сколько "логику". А делать много гибкой (требования-то будут меняться) логики на плюсах — это уметь надо. Даже при наличии опыта, помахнуться очень легко... и смотри ниже...

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

"- знание Oracle на уровне разработчика (SQL, PL/SQL)"
Угу, угу... В Е-бурге "Восточный ветер" тоже полагал (а может и все еще полагает — не знаю), что Oracle их спасет...
Но суть в том, что в задачах биллинга возникает очень интеесная структура баз в виде "острой пирамиды", когда 80-85% объема приходится на 3-4 таблицы, и на них же падают наиболее критичные по времени операции (а весь остальной табличный зоопарк — это в основном многоуровневое описание "особых условий"). И кроме того, в этих задачах не очень стандартное соотношение операций запись/читение — сильно смещенное в пользу записи.
Все перечисленное в сумме очень сильно противоречит основной "заточке" SQL северов и "крутость" того же Oracle может вообще не проявиться (особенно если сравнивать с "не-SQL" решениями).

"- опыт использования CORBA"
Здесь может быть и все нормально (а может и нет). Все зависит от того, где корбу собираются использовать — в стыковке со внешним софтом или во внутренней архитектуре... То есть опять же настораживет, но может и нормально.

Здравствуйте, EXO, Вы писали:

EXO>(Кстати привет )

Привет.

EXO>Да знаю я, что она может работать хорошо, если будет написана по уму. Только обойдется такое в наше время очень дорого (раньше "время" было другое — в смысле его было больше). Такую архитектуру нельзя "выдать быстро", а оно наверняка потребуется... в резултате — выйдет абы как.

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

EXO>"- опыт использования STL "
EXO>В STL отвратно работают map-ы. На столько отвратно, что мне в свое время пришлось их переписать. В это уже требует не "опыт использования STL", а опыт "поторшения" внутренностей плюсовых шаблонов. Похоже данный вопрос не исслеовался, что настораживает (в смыле промашек по предидущему пункту).

Вы просто не умеете их готовить. Сейчас большая часть Яндексовских серверов написана на C++ с использованием STL в том числе и map-ов. Они выдерживают очень большую нагрузку.

EXO>"- знание Oracle на уровне разработчика (SQL, PL/SQL)"
EXO>Угу, угу... В Е-бурге "Восточный ветер" тоже полагал (а может и все еще полагает — не знаю), что Oracle их спасет...
EXO>Но суть в том, что в задачах биллинга возникает очень интеесная структура баз в виде "острой пирамиды", когда 80-85% объема приходится на 3-4 таблицы, и на них же падают наиболее критичные по времени операции (а весь остальной табличный зоопарк — это в основном многоуровневое описание "особых условий"). И кроме того, в этих задачах не очень стандартное соотношение операций запись/читение — сильно смещенное в пользу записи.
EXO>Все перечисленное в сумме очень сильно противоречит основной "заточке" SQL северов и "крутость" того же Oracle может вообще не проявиться (особенно если сравнивать с "не-SQL" решениями).

Oracle это стандарт дефакто при работе с деньгами, просто из-за надежности, масштабируемости, удобства резервного копирования, etc. В таких системах кроме скорости активно используются транзакции, по честностному их написать на file storage это еще та задача.

EXO>"- опыт использования CORBA"
EXO>Здесь может быть и все нормально (а может и нет). Все зависит от того, где корбу собираются использовать — в стыковке со внешним софтом или во внутренней архитектуре... То есть опять же настораживет, но может и нормально.

Corba это просто сложившийся стандарт взаимодействия между серверами в Яндекс.

Здравствуйте, Anatolix, Вы писали:

[...]

A>Для информации: такая платформенная связка в Яндекс работает уже 5 лет, и выдерживает такие нагрузки, которыми почти никто в России больше похвастаться не может.

А можно узнать, какие именно нагрузки?! кол-во транзакций в секунду или что?

Спасибо.

Здравствуйте, Anatolix, Вы писали:

A>Здравствуйте, EXO, Вы писали:
A>Система существует уже несколько лет, и разрабатывается командой из нескольких человек, считается одним из основных конкурентных преимуществ Яндекса.

Жиным выделил я. О чем собственно и речь: раньше "время было медленнее".

A>Вы просто не умеете их готовить. Сейчас большая часть Яндексовских серверов написана на C++ с использованием STL в том числе и map-ов. Они выдерживают очень большую нагрузку.

Ну и? Знаю я как они работают и как устроены...
История такова:
— был продукт, который был сделан на "самодельных" структурах данных. Насальство решило переписать его "на стандартный STL".
— Переписали. Быстродействие упало примерно раз в 20.
— Сперва тоже решили, что "не умеем готовить", полезли в эхи, в примеры использования... кое-что поменяли, взяли другую версию STL, улучшили резултат примерно на 60%. Но это все равно отставание больше порядка от прежнего...
— тогда я полез в исходники самого STL, посмотрел как там работают хеши и прочие потроха, стало ясно, что так оно и должно быть...
— пришлось плотно засесть самому за кодирование и сделать аналог map-ов с тем же интерфейсом шаблонов но
1)он содержал 4 разных алгоритма хеширования и автоматом переключался между ними на основе статистики операций чтение/запись/изменение ключа.
2) в рамках одного алгоритма динамически менял размерности хешей и хеш-функци. Причем делал это через дополнительную размерность хеш-матрицы (то есть без остановки работы. какое-то время могло сосуществовать одновременно два алгоритма хеширования — старый и новый).
3) ну и разумеется имел дополнительные (сверх стандартного) функции за которые можно было подергать и поуправлять вручную. Правда в основном продукте это не использовалось, чтобы не переписывать код.
В итоге мы венули свой "потерянный" порядок, но рассматривать STL как платформу для time-критичных приложений, я уже не буду...
(У меня было желание опубликовать патч к STL, однако начальство воспротивилось. Так что вот просто в кратце сказал где можно нарыть порядок.)

A> Oracle это стандарт дефакто при работе с деньгами,

Ну и...? Это отменяет необходимость думать?

A> просто из-за надежности, масштабируемости, удобства резервного копирования, etc.

... и к тому же итоговые суммы можно скинуть и в Oracle. Это-то как раз не поблема.

A> В таких системах кроме скорости активно используются транзакции, по честностному их написать на file storage это еще та задача.

Ты правда думаешь, что надежные транзакции есть только в Oracle? Не верю...

A>Corba это просто сложившийся стандарт взаимодействия между серверами в Яндекс.

А, ну между серверами — ето нормально. Ок.

Здравствуйте, Аноним, Вы писали:

A>>Для информации: такая платформенная связка в Яндекс работает уже 5 лет, и выдерживает такие нагрузки, которыми почти никто в России больше похвастаться не может.

А>А можно узнать, какие именно нагрузки?! кол-во транзакций в секунду или что?

http://stat.yandex.ru/

Здравствуйте, EXO, Вы писали:

EXO>- Сперва тоже решили, что "не умеем готовить", полезли в эхи, в примеры использования... кое-что поменяли, взяли другую версию STL, улучшили резултат примерно на 60%. Но это все равно отставание больше порядка от прежнего...
EXO>- тогда я полез в исходники самого STL, посмотрел как там работают хеши и прочие потроха, стало ясно, что так оно и должно быть...
EXO>- пришлось плотно засесть самому за кодирование и сделать аналог map-ов с тем же интерфейсом шаблонов но
EXO> 1)он содержал 4 разных алгоритма хеширования и автоматом переключался между ними на основе статистики операций чтение/запись/изменение ключа.

Ну что смеяться то. Поручить контейнеру самому выбрать алгоритм хэширования т.к. программист не может сделать это сам? Если честно у меня нет никакого желания чтобы вставка в хэш занимала неопределенное время только потому, что контейнер вдруг неожиданно решил поменять алгоритм, пересчитать все хэши и все перераскидать по hash-bucket-ам.

EXO> 2) в рамках одного алгоритма динамически менял размерности хешей и хеш-функци. Причем делал это через дополнительную размерность хеш-матрицы (то есть без остановки работы. какое-то время могло сосуществовать одновременно два алгоритма хеширования — старый и новый).
EXO> 3) ну и разумеется имел дополнительные (сверх стандартного) функции за которые можно было подергать и поуправлять вручную. Правда в основном продукте это не использовалось, чтобы не переписывать код.
EXO>В итоге мы венули свой "потерянный" порядок, но рассматривать STL как платформу для time-критичных приложений, я уже не буду...
EXO>(У меня было желание опубликовать патч к STL, однако начальство воспротивилось. Так что вот просто в кратце сказал где можно нарыть порядок.)

Вообщем что я скажу. Любой вменяемый программист способен переписать STL лучше чем он есть сейчас и написать свои ultimate контейнеры. Подумаешь что могли написать Степанов с Ли — фигня какая. Ok допустим переписали. Потом появляется еще один вменяемый программист и пишет контейнеры еще лучше, подумаешь почему бы не написать лучше чем сосед. И вот у тебя в проекте уже 2 библиотеки контейнеров. А потом 3.

STL хорош уже хотя бы тем что является стандартом. Конечно почти любой алгоритм можно для конкретного частного случая написать быстрее — когда надо пишем. Но использовать const char* в программе везде, только потому что std::string в порядки раз тормознее т.к. копируется каждый раз целиком это глупо. Ускоряй там где надо, даже в time critical серверах количество критичного кода не превышает 3-5%.

A>> Oracle это стандарт дефакто при работе с деньгами,
EXO>Ну и...? Это отменяет необходимость думать?
А кто сказал что не думали?

A>> просто из-за надежности, масштабируемости, удобства резервного копирования, etc.
EXO>... и к тому же итоговые суммы можно скинуть и в Oracle. Это-то как раз не поблема.
Ну вот они и скидываются, ты что думаешь там одним SQL-ем чтоли все считается, там нормальный C++ сервер.

A>> В таких системах кроме скорости активно используются транзакции, по честностному их написать на file storage это еще та задача.
EXO>Ты правда думаешь, что надежные транзакции есть только в Oracle? Не верю...

Еще они есть в MS-SQL который под Windows, плюс есть всякие экзотичекие базы типа DB2 и т.п. с которыми связываться не охота, и open source базы с которыми связываться страшно. если подумать то альтернативы особой то и нету, ты бы что предложил?

A>>Corba это просто сложившийся стандарт взаимодействия между серверами в Яндекс.

EXO>А, ну между серверами — ето нормально. Ок.

Здравствуйте, Anatolix, Вы писали:

A>Ну что смеяться то. Поручить контейнеру самому выбрать алгоритм хэширования т.к. программист не может сделать это сам?

Сильно пахнет флеймом.
Давай попробуем его избежать. Ок?

А ответ на вопрос простой: было большое количество кода, который писался под стандартный STL и не должен был меняться. Разумеется если код писался бы "под свою библиотеку" он мог бы явно обработать назначение алгоритма.

A>Вообщем что я скажу. Любой вменяемый программист способен переписать STL лучше чем он есть сейчас и написать свои ultimate контейнеры.

Не любой, но многие.

A> Потом появляется еще один вменяемый программист и пишет контейнеры еще лучше, подумаешь почему бы не написать лучше чем сосед. И вот у тебя в проекте уже 2 библиотеки контейнеров. А потом 3.

Если все эти библиотеки поддерживают интефейс STL на внешнем уровне, то в проекте будет не 3 библиотеки,
а одна — лучшая из этих трех. И в чем проблема?
Другое дело, что для всех ли проектов этот интерфейс лучший? Не факт. И не факт, что стандартность окупает минусы.

A>STL хорош уже хотя бы тем что является стандартом. Конечно почти любой алгоритм можно для конкретного частного случая написать быстрее — когда надо пишем. Но использовать const char* в программе везде, только потому что std::string в порядки раз тормознее т.к. копируется каждый раз целиком это глупо. Ускоряй там где надо, даже в time critical серверах количество критичного кода не превышает 3-5%.

Здесь в целом соглашусь. Есть только одно но: а зачем тогда для "некритичного кода" C++?
Вспомни мой первый тезис: "Время стало слишком быстрым, чтобы писать на плюсах некритичный код".
Кстати плюсы я весьма люблю (как-никак больше 12 лет на них прописал), но ...

EXO>>... и к тому же итоговые суммы можно скинуть и в Oracle. Это-то как раз не поблема.
A>Ну вот они и скидываются, ты что думаешь там одним SQL-ем чтоли все считается, там нормальный C++ сервер.

Дык. С этого разговор и начинался (тезис про время)...

EXO>>Ты правда думаешь, что надежные транзакции есть только в Oracle? Не верю...
A>Еще они есть в MS-SQL который под Windows, плюс есть всякие экзотичекие базы типа DB2 и т.п. с которыми связываться не охота, и open source базы с которыми связываться страшно. если подумать то альтернативы особой то и нету, ты бы что предложил?

Предлагать "от фонаря" не возьмусь — это надо хорошо знать задачу. Но альтернативы есть. Всегда.
У меня например сейчас в проекте вот это: http://erlang.se/doc/doc-5.4.8/lib/mnesia-4.2.2/doc/html/index.html
Решение не для всех случаев, разумеется. Но к транзакциям притензий нет и к надежности — тоже.
Думаю, что можно найти и еще варианты.

Здравствуйте, EXO, Вы писали:

EXO>Все перечисленное в сумме очень сильно противоречит основной "заточке" SQL северов и "крутость" того же Oracle может вообще не проявиться (особенно если сравнивать с "не-SQL" решениями).

Не могли бы вы поподробнее объяснить что понималось под "не-SQL" решениями"?

Здравствуйте, EXO, Вы писали:

EXO>А ответ на вопрос простой: было большое количество кода, который писался под стандартный STL и не должен был меняться. Разумеется если код писался бы "под свою библиотеку" он мог бы явно обработать назначение алгоритма.

Чем эта штука отлимчается от еще одной реализации STL которых миллион? Почему не взять готовую, ведь ты не думаешь что никому в голову не пришло это уже написать?

A>> Потом появляется еще один вменяемый программист и пишет контейнеры еще лучше, подумаешь почему бы не написать лучше чем сосед. И вот у тебя в проекте уже 2 библиотеки контейнеров. А потом 3.

EXO>Если все эти библиотеки поддерживают интефейс STL на внешнем уровне, то в проекте будет не 3 библиотеки,
EXO>а одна — лучшая из этих трех. И в чем проблема?

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

EXO>Другое дело, что для всех ли проектов этот интерфейс лучший? Не факт. И не факт, что стандартность окупает минусы.

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

A>>STL хорош уже хотя бы тем что является стандартом. Конечно почти любой алгоритм можно для конкретного частного случая написать быстрее — когда надо пишем. Но использовать const char* в программе везде, только потому что std::string в порядки раз тормознее т.к. копируется каждый раз целиком это глупо. Ускоряй там где надо, даже в time critical серверах количество критичного кода не превышает 3-5%.

EXO>Здесь в целом соглашусь. Есть только одно но: а зачем тогда для "некритичного кода" C++?
EXO>Вспомни мой первый тезис: "Время стало слишком быстрым, чтобы писать на плюсах некритичный код".
EXO>Кстати плюсы я весьма люблю (как-никак больше 12 лет на них прописал), но ...

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

EXO>>>... и к тому же итоговые суммы можно скинуть и в Oracle. Это-то как раз не поблема.
A>>Ну вот они и скидываются, ты что думаешь там одним SQL-ем чтоли все считается, там нормальный C++ сервер.
EXO>Дык. С этого разговор и начинался (тезис про время)...

Я не понимаю тезис про сокращение времени разработки с одновременным предложением переписать STL.

EXO>>>Ты правда думаешь, что надежные транзакции есть только в Oracle? Не верю...
A>>Еще они есть в MS-SQL который под Windows, плюс есть всякие экзотичекие базы типа DB2 и т.п. с которыми связываться не охота, и open source базы с которыми связываться страшно. если подумать то альтернативы особой то и нету, ты бы что предложил?

EXO>Предлагать "от фонаря" не возьмусь — это надо хорошо знать задачу. Но альтернативы есть. Всегда.
EXO>У меня например сейчас в проекте вот это: http://erlang.se/doc/doc-5.4.8/lib/mnesia-4.2.2/doc/html/index.html
EXO>Решение не для всех случаев, разумеется. Но к транзакциям притензий нет и к надежности — тоже.
EXO>Думаю, что можно найти и еще варианты.

Риски сильно больше — ну нафиг.

Здравствуйте, Anton Batenev, Вы писали:

AB>Здравствуйте, EXO, Вы писали:

EXO>>Все перечисленное в сумме очень сильно противоречит основной "заточке" SQL северов и "крутость" того же Oracle может вообще не проявиться (особенно если сравнивать с "не-SQL" решениями).

AB>Не могли бы вы поподробнее объяснить что понималось под "не-SQL" решениями"?

Если например система требует массивных write операций то имеет смысл
рассмотреть запись во flat file (или ту же fastdb) и делать пакетный update SQL.
Может получится выигрыш в разы. Нечто типа отложенной (асинхронной) записи.

Также как ни странно на первый взгляд звучит но отключение параллельности
исполнения таких запросов на запись тоже может дать ощутимый выигрыш.
Если запись это простой append то only-one-writer вместо multiple-writers-with-sharing-lock
может поднять быстродествие иногда на порядок. Надо смотреть на конкретную задачу.

По поводу "не SQL решений" — DB движок оптимизированный под конкретную задачу
естесвенно лучше чем SQL — sql хорош на чтение. Но динамическая модификация это
не его сильная сторона. Особенно частые короткие записи.
В принципе связка operational custom DB (frontend) + SQL DB (backend, olap, etc.)
рулит.

Ну и на тот же google посмотреть как на не SQL решение...

Здравствуйте, c-smile, Вы писали:

AB>>Не могли бы вы поподробнее объяснить что понималось под "не-SQL" решениями"?
CS>Если например система требует массивных write операций то имеет смысл
CS>рассмотреть запись во flat file (или ту же fastdb) и делать пакетный update SQL.
CS>Может получится выигрыш в разы. Нечто типа отложенной (асинхронной) записи.

Да, но если этот пакетный update достаточно велик, а на таблицу в вершине вышеозначенной пирамиды понаставлено индексов, триггеров, обрабатывающих ХП для того, чтобы поступающие данные как-то раскидывать / обрабатывать, то этот пакетный update во время внесения данных будет "ставить раком" весь сервер БД.

А от системы билинга (в моем случае) требуется непрерывная работа.

CS>Также как ни странно на первый взгляд звучит но отключение параллельности
CS>исполнения таких запросов на запись тоже может дать ощутимый выигрыш.

М... а как такое, например, можно сделать в MSSQL? Oracle?

CS>Если запись это простой append то only-one-writer вместо multiple-writers-with-sharing-lock
CS>может поднять быстродествие иногда на порядок. Надо смотреть на конкретную задачу.

Могу описать конкретную задачу, если, конечно, вам это интересно

Системы предачи данных. Непрерывный поток данных об основной единице измерения. В моем случае это байты и секунды. Соответственно, базовый "удар" принимают на себя две таблицы в БД.

Во первых, требуется эти данные внести. На самом деле, эти данные, как они есть, нужны только в качестве лога, и часто не требуются. Часто требуются уже сгруппированные данные по требуемым интервалам времени (часы / дни / месяцы / сессии) и направлениям (входящие / исходящие / внутренние / внешние / пиринговые).

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

Чем больше интервал времени между операциями, тем больше возможности у клиента превысить кредитный лимит. Само по себе, превышение кредитного лимита — это неизбежное зло. У некоторых групп клиентов, это зло восполнимо последующим погашением клиентом задолженности (например, клиенты, которым в конце месяца выставляются счета к оплате). Однако, существуют группы клиентов, которые получают услугу как разовую (например, по картам оплаты), где потери от несвоевременной блокировки невосполнимы.

Ну и задача сводится классически к:

1. Минимизации финансовых потерь;
2. Своевременному предоставлению информации о состоянии счета и операций со счетом клиенту;
3. Аналитике.

Операции 1, 2 критичны ко времени исполнения.

Предложения по организации всего этого хозяйства?

Здравствуйте, Anatolix, Вы писали:
A>Чем эта штука отлимчается от еще одной реализации STL которых миллион? Почему не взять готовую, ведь ты не думаешь что никому в голову не пришло это уже написать?

Ну во-первых, поддерживающих полный STL-совместимый интерфейс — не так уж и много. Я в свое время смотрел, подходящей не нашлось. Они наверняка есть, но подозреваю, что ситуация такая же как и у меня — как только комплект становится серьезен, возникают проблемы с публикацией.

A>>> Потом появляется еще один вменяемый программист и пишет контейнеры еще лучше, подумаешь почему бы не написать лучше чем сосед. И вот у тебя в проекте уже 2 библиотеки контейнеров. А потом 3.
EXO>>Если все эти библиотеки поддерживают интефейс STL на внешнем уровне, то в проекте будет не 3 библиотеки,
EXO>>а одна — лучшая из этих трех. И в чем проблема?
A>Проблема в том, что программисты потратили время на написание библиотеки которая особо не нужна, а не на проект. Если в проекте нет централизованного архитектора, то эта штука расползется и фреймворки займут большую часть проекта, а конверсия стрингов и контейнеров из типа в тип займет большую часть времени выполнения. А если архитектор есть, то как минимум странно что он вообще опустил 3 однотипных фреймворка.

Таки увлекаешься флеймом. Я специально оставил квотинг: тезис про 3 библиотеки — твой. ( То есть ты критикуешь свою собственную посылку. )

Напоминаю уже написанное мной:
— первоначально была одна библиотека — самописная и не в этом проекте, а в старом продукте.
— при разработке проекта архитектор решил использовать "стандартный STL" по всему проекту (и это действительно оказалось ошибкой)
— встал выбор:
1. либо переписать прикладной код time-критичных участков и удалить оттуда STL (и соответсвенно получить две библиотеки в проекте одноворенменно)
2. либо доработать сам STL и заменить его по всему проекту, сохранив единство платформы.
— был выбран второй вариант (хотя на первом этапе он дороже). И на мой взгляд — правильно, хотя еще лучше было изначально не гнаться за "стандартностью" и оставить весь проект на той же самодельной библиотеке, на которй была реализована предидущая версия.


A>Я в своем ЖЖ уже писал про то что бывает когда слишком сильно занимаешься инструментарием.

Я читал — хорошая статья (хотя я там же тебе и возражал). На мой взгляд проблема лечится просто — фиксированным бюджетом проекта.

A>Вообщем явной выгоды нету, рисков полно, реализаций STL полно.

Ну здесь (и ниже) я несколько иначе оцениваю риски. Возможно это субъективное, поскольку чаще выигрывал, чем проигрывал.

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

Гм. Занимался четырмя стыковками:
1. C — TCL
2. C — Erlang
3. C — Python
4. C — Java

В случае 1 и 2 вообще никаких проблем не возникло (а это были стыковки с весьма большими потоками).
В случае 3 — действительно текло. Но не исключаю, что я просто не до конца разобрался с DecRef-ами у питона (есть мысль как нибудь в свободное время еще поковыряться, посмотрим).
В случае 4 — ничего сказать не могу. Интерфейс там у жавы весьма заморочен, да и больших нагрузок не давали.
Так что риски действительно есть, но ничего не стоит погонять разные варианты на макетах перед началом проекта, что не слишком дорого и очень существенно снизит риски.

A>Я не понимаю тезис про сокращение времени разработки с одновременным предложением переписать STL.

Уже написал, что преписывание STL было вынужденным решением, поскольку он оказался в time-критичных участках. Переписывание всех этих участков заняло бы сравнимое время плюс нарушило однородность проекта.

EXO>>Предлагать "от фонаря" не возьмусь — это надо хорошо знать задачу. Но альтернативы есть. Всегда.
EXO>>У меня например сейчас в проекте вот это: http://erlang.se/doc/doc-5.4.8/lib/mnesia-4.2.2/doc/html/index.html
EXO>>Решение не для всех случаев, разумеется. Но к транзакциям притензий нет и к надежности — тоже.
EXO>>Думаю, что можно найти и еще варианты.

A>Риски сильно больше — ну нафиг.

Ну можно конечно и "шарахаться" от рисков — тоже вариант. А можно с этими рисками поработать в плане их снижения. Через те же макеты, например.

Здравствуйте, Anton Batenev, Вы писали:


AB>Системы предачи данных. Непрерывный поток данных об основной единице измерения. В моем случае это байты и секунды. Соответственно, базовый "удар" принимают на себя две таблицы в БД.

AB>Во первых, требуется эти данные внести. На самом деле, эти данные, как они есть, нужны только в качестве лога, и часто не требуются. Часто требуются уже сгруппированные данные по требуемым интервалам времени (часы / дни / месяцы / сессии) и направлениям (входящие / исходящие / внутренние / внешние / пиринговые).

AB>А во вторых, эти данные нужно обработать. По сути, обработка заключается в снятии денег со счетов клиентов, проверке счетов на превышение кредитного лимита (и, соответственно, блокированию счетов, превышающих кредитный лимит).

AB>Чем больше интервал времени между операциями, тем больше возможности у клиента превысить кредитный лимит. Само по себе, превышение кредитного лимита — это неизбежное зло. У некоторых групп клиентов, это зло восполнимо последующим погашением клиентом задолженности (например, клиенты, которым в конце месяца выставляются счета к оплате). Однако, существуют группы клиентов, которые получают услугу как разовую (например, по картам оплаты), где потери от несвоевременной блокировки невосполнимы.

AB>Ну и задача сводится классически к:

AB>1. Минимизации финансовых потерь;
AB>2. Своевременному предоставлению информации о состоянии счета и операций со счетом клиенту;
AB>3. Аналитике.

AB>Операции 1, 2 критичны ко времени исполнения.

AB>Предложения по организации всего этого хозяйства?

Скажем одна запись в таблице клиент-деньги это
struct r
{
char id[16];
currency balance;
};

итого 32 байта + еще скажем 48байт на индекс/запись = итого 80 байт.
Одна машина с 1gb ram может хранить в оперативной памяти примерно 13,000,000 таких записей с индексом.
Это население города Москва.

Т.е. одна такая машина может оперативно выполнять функции
"может ли этот клиент звонить?"
"транзакция закончена с суммой N" (дебет balance)

Считаем далее:

AMD Athlon 64 Dual Core делает 18500 MIPS (Million instructions per second)

Получение оддног TCP/IP пакета это примерно 30000 инструкций + скажем 10000 инструкций на поиск
в памяти ао индексу и все остальное.

Итого имеем: 18500 * 1M / 40000 =

462500 запросов в секунду мы можем отработать (если сетка позволит)

Итого одна машина спокойно справляется с биллингом интернет трафика города Москва.

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

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

А уж как правильно кластеризовать индексы и хранилища в SQL то тебе расскажет db architect.

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

Здравствуйте, c-smile, Вы писали:

CS>Одна машина с 1gb ram может хранить в оперативной памяти примерно 13,000,000 таких записей с индексом.
CS>Это население города Москва.

Предлагаю не мыслить такими категориями а снизить планку, скажем, до 10 000 одновременно подключенных клиентов, до 20 000 клиентов в базе, о которых информация есть и до 20 000 клиентов о которых информации нет (карты оплаты). Т.е. максимальная обслуживающая способность сети составляет 25% (что является нормой, например, для телефонных станций). Это упростит наши рассуждения.

Итого, имеем в памяти

40 000 * 80 = 3 200 000 байт = 3125 KB = 3.05 MB * 4 фазы луны в месяц = 12.2 MB

Копейки, согласен. Хотя, мы не учли еще ряд характеристик, но сути это не поменяет — 2GB памяти для хранения всего снимка данных по клиентам вполне хватит.

CS>Т.е. одна такая машина может оперативно выполнять функции
CS>"может ли этот клиент звонить?"
CS>"транзакция закончена с суммой N" (дебет balance)

А вот теперь по поводу оперативности. Для того, чтобы ответить на вопрос "может ли этот клиент звонить?" необходимо производить синхронизацию данных с БД — например, добавление клиента, удаление клиента, измнениение тарифного плана, добавление новых карт, пополнение баланса, измнение кодов доступа, IP адресов, маршрутов и т.д. и, в соответствии с этими изменениями, корректировать состояние "можно" / "нельзя".

"Транзакция закончена с суммой N" — эта формулировка не совсем корректна. Она должна быть другой: "Превышен кредитный лимит. Завершить открытые транзакции, заблокировать счет."

Т.о. получаем некоторый агрегат, который состоит из БД, снимка части БД и нечто, что их синхронизирует. Думаю, что на это "нечто" так же можно возложить функции ответа на вопрос "можно" / "нельзя", если можно, то с какими параметрами (адреса, маршруты, алгоритмы компрессии и прочее)... Назовем этот агрегат сервером приложений.

Я правильно понимаю идею?

Теперь посмотрим на путь прохождения данных.

Данные тарификации пришли на СП. СП провел некоторую работу на основе данных из снимка, расчитал сумму денег, которую нужно снять в соответствии с тарифом и типом пришедших данных, снял деньги, проверил остаток на счету, установил значения "можно" / "нельзя", сбросил данные в лог БД. По прошествии некоторого времени этот СП должен опросить свой снимок на предмет того — у кого сколько денег / байт / минут на счету и сбросить данные в БД:

а) Для отражения данных аналитикам.
б) Чтобы в случае, если по воле бога все вдруг накроется медным тазом, не потерять кучу денег.

С аналитиками все понятно — им не особо нужны данные за текущие сутки, так что они могут подождать и до завтра.

А вот со вторым... С какой периодичностью все должно сбрасываться в БД? Кого будут садить на кол, если вдруг случайно заглючит супер-бупер дорогой управляемый UPS и выведет компы в перезагрузку или сгорит какая-либо из комплектующих сервера или кому-то в голову придет шальная мысль задеть кнопку питания?

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

Предложения?

CS>Итого одна машина спокойно справляется с биллингом интернет трафика города Москва.

Хорошая шутка

CS>Схематично конечно, но даже если разделить все на три во имя "неизбежных на море случайностей"
CS>все равно пойдет.

Пока что нет, не пойдет "Во всем мне хочется дойти до самой сути"

AB>"Транзакция закончена с суммой N" — эта формулировка не совсем корректна. Она должна быть другой: "Превышен кредитный лимит. Завершить открытые транзакции, заблокировать счет."

Странно. Я всегда считал, что при открытии транзакции сервер говорит "разрешаю начать транзакцию по такому-то счету с максимальной продолжительностью такой-то". И при превышении продолжительности транзакция обрубается аппаратно. И ни какого перерасхода не происходит. Разве не так?

Здравствуйте, Mikhail Polykovsky, Вы писали:

AB>>"Транзакция закончена с суммой N" — эта формулировка не совсем корректна. Она должна быть другой: "Превышен кредитный лимит. Завершить открытые транзакции, заблокировать счет."
MP>Странно. Я всегда считал, что при открытии транзакции сервер говорит "разрешаю начать транзакцию по такому-то счету с максимальной продолжительностью такой-то". И при превышении продолжительности транзакция обрубается аппаратно. И ни какого перерасхода не происходит. Разве не так?

Так, например, для IP телефонии, когда гейт "знает" направление звонка. Для передачи данных в общем случае это не так. Трафик может делиться на зоны при этом в одной сессии пользователь может посетить разные зоны => снимается разная стоимость за минуту или байт.

Здравствуйте, Anton Batenev, Вы писали:

AB>Данные тарификации пришли на СП. СП провел некоторую работу на основе данных из снимка, расчитал сумму денег, которую нужно снять в соответствии с тарифом и типом пришедших данных, снял деньги, проверил остаток на счету, установил значения "можно" / "нельзя", сбросил данные в лог БД. По прошествии некоторого времени этот СП должен опросить свой снимок на предмет того — у кого сколько денег / байт / минут на счету и сбросить данные в БД:

AB>а) Для отражения данных аналитикам.
AB>б) Чтобы в случае, если по воле бога все вдруг накроется медным тазом, не потерять кучу денег.

AB>С аналитиками все понятно — им не особо нужны данные за текущие сутки, так что они могут подождать и до завтра.

AB>А вот со вторым... С какой периодичностью все должно сбрасываться в БД? Кого будут садить на кол, если вдруг случайно заглючит супер-бупер дорогой управляемый UPS и выведет компы в перезагрузку или сгорит какая-либо из комплектующих сервера или кому-то в голову придет шальная мысль задеть кнопку питания?

По большому счету — ОС может кэшировать запросы на запись, и то, что Вы считаете находится в БД — на самом деле там не находится [Это я так утрирую немного, но все возможно]

Сохраняйте на файловой системе, причем можно сохранять не весь объём данных, а расчитанные значения, которые Вы потом положите в БД, и по ним будете считать аналитику.

ЗЫ
ИЛИ Я чего-то непонял ?