Добрый день всем!

Не программировал уже года три (сам С++ ник). Сейчас занимаюсь больше продукт менеджментом и прочей красивой ерундой.
На горизонте есть Задача. Которую, как мне кажется, нужно решать выйдя за круг своих предыдущих знаний (не создавать велосипеды на С++). Может быть Erlang, которым я проникся за последние два дня, мне поможет?

Описываю задачу:

Исходные данные:
1. Есть база данных с 50 млн клиентов.
2. Каждый клиент владеет в среднем двумя устройствами генерации трафика (телефон, GPRS модем и т.д.) Итого: 100 млн устройств.
3. Максимальное количество устройств на одного клиента — 100 тыс. Минимальное — 1 (одна штука).
4. Для каждого клиента, в системе, хранится баланс.
5. В день, клиенты генерируют 150-200 млн событий.
6. В часы наибольшей нагрузки приходится 2 события на одного клиента.
7. На каждое событие, приходится три обращения к балансу клиента (получить значение и обновить значение — это одно обращение)
8. Интерфейс со стороны сторонних систем TCP/IP.

---------------
Краткие требования.
1. 99.999
2. Скорость обработки одного запроса в интервале от [0.25..1] миллисекунды.
3. Потеря даже одной команды списания баланса невозможна.


Предположения
--------------
1. В память одного компа все не влезет. Фактически речь идет об необходимости распределенной in-memory DB.
2. Необходима горячая замена серверов в кластере.
3. Все команды по получению, предварительно писать на диск, или передавать на другой сервер.


Что скажете, Уважаемые?

Здравствуйте, Gerasim.mu, Вы писали:
GM>Описываю задачу:

GM>Исходные данные:
GM>1. Есть база данных с 50 млн клиентов.
.....
GM>5. В день, клиенты генерируют 150-200 млн событий.
GM>6. В часы наибольшей нагрузки приходится 2 события на одного клиента.

Ну ясно что не mnesia. Не потянет.

Здравствуйте, http://walrus16.blogspot.com/, Вы писали:

HWB>Здравствуйте, Gerasim.mu, Вы писали:
GM>>Описываю задачу:

GM>>Исходные данные:
GM>>1. Есть база данных с 50 млн клиентов.
HWB>.....
GM>>5. В день, клиенты генерируют 150-200 млн событий.
GM>>6. В часы наибольшей нагрузки приходится 2 события на одного клиента.

HWB>Ну ясно что не mnesia. Не потянет.

Интересно, откуда дровишки?
К примеру есть это, плюс тут само собой напрашивается партиционирование данных (т.е. не надо всё сразу хранить в одной базе). В общем — надо архитекторить + писать прототипчики.

Здравствуйте, http://walrus16.blogspot.com/, Вы писали:

GM>>Исходные данные:
GM>>1. Есть база данных с 50 млн клиентов.
HWB>.....
GM>>5. В день, клиенты генерируют 150-200 млн событий.
GM>>6. В часы наибольшей нагрузки приходится 2 события на одного клиента.

HWB>Ну ясно что не mnesia. Не потянет.

Не факт. Если они генерируют 200 млн за день в сумме, то это не так уж и много. Пик — 100 млн. в час, то есть 70 тыс/сек — это уже хуже. Мнезия конечно тормозная, но подергаться есть куда.
1) Применить memory-only таблицы и 64-битный Эрланг. В этом случае снимается ограничение на 2Gb-таблица.
2) Раскидать таблицы по разным машинам, устроить дублирование каждой порции на второй машине, устроив там резервные копии.
3) Аккуратно посмотреть, где можно применить dirty-транзакции, и как избежать распределенных блокировок.
4) Зацепить машины кластера какой-нибудь низколатентной сеткой, например FibreChannel или коммутатором InfiniBand. Это может поправить скорость транзакций.
5) Померять это на прототипе.
6) В крайнем случае — отказаться от мнезии. Все равно изобразить такое на Эрланге будет проще.

А вот насчет задержки обработки отдельного сообщения до 1 миллисекунды — я совсем не уверен, сможет ли Эрланг такое дать. Это вообще гарантировать тяжело, учитывая задержки в TCP/IP, и размер кванта оперсистемы в 10-15 msec.

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

G>А вот насчет задержки обработки отдельного сообщения до 1 миллисекунды — я совсем не уверен, сможет ли Эрланг такое дать. Это вообще гарантировать тяжело, учитывая задержки в TCP/IP, и размер кванта оперсистемы в 10-15 msec.

По идее были где-то в листе обсуждения по поводу добавления наносекундных таймеров (на поддерживающих такое ОС, правда я не знаю какие это)

Всем большое спасибо за участие, коменты внизу.


G>Не факт. Если они генерируют 200 млн за день в сумме, то это не так уж и много. Пик — 100 млн. в час, то есть 70 тыс/сек — это уже хуже. Мнезия конечно тормозная, но подергаться есть куда.
G>1) Применить memory-only таблицы и 64-битный Эрланг. В этом случае снимается ограничение на 2Gb-таблица.
G>2) Раскидать таблицы по разным машинам, устроить дублирование каждой порции на второй машине, устроив там резервные копии.
G>3) Аккуратно посмотреть, где можно применить dirty-транзакции, и как избежать распределенных блокировок.
G>4) Зацепить машины кластера какой-нибудь низколатентной сеткой, например FibreChannel или коммутатором InfiniBand. Это может поправить скорость транзакций.
G>5) Померять это на прототипе.
G>6) В крайнем случае — отказаться от мнезии. Все равно изобразить такое на Эрланге будет проще.

А если не 64 битный? Я правда еще не считал разницу в стоимости хранении одного клиента, при использовании 32 или 64 битных серверов. Попробую узнать во сколько обходится хранение 1 млн клиентов. То есть все таки использовать Мнезию предлагаете? Хотя бы начать строить прототип с ее использованием? А вот такой вопрос тогда. В любом случае, информацию нужно регулярно скидывать на диск, хотя бы раз в биллинговый период. Это средствами мнезии ведь тоже возможно?

G>А вот насчет задержки обработки отдельного сообщения до 1 миллисекунды — я совсем не уверен, сможет ли Эрланг такое дать. Это вообще гарантировать тяжело, учитывая задержки в TCP/IP, и размер кванта оперсистемы в 10-15 msec.

Упс, сорри моя опечатка: от 0.25 до 1 секунды.

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

GM>Описываю задачу:

GM>Исходные данные:
GM>1. Есть база данных с 50 млн клиентов.
GM>2. Каждый клиент владеет в среднем двумя устройствами генерации трафика (телефон, GPRS модем и т.д.) Итого: 100 млн устройств.
GM>3. Максимальное количество устройств на одного клиента — 100 тыс. Минимальное — 1 (одна штука).
GM>4. Для каждого клиента, в системе, хранится баланс.
GM>5. В день, клиенты генерируют 150-200 млн событий.
GM>6. В часы наибольшей нагрузки приходится 2 события на одного клиента.
GM>7. На каждое событие, приходится три обращения к балансу клиента (получить значение и обновить значение — это одно обращение)
GM>8. Интерфейс со стороны сторонних систем TCP/IP.

GM>---------------
GM>Краткие требования.
GM>1. 99.999
GM>2. Скорость обработки одного запроса в интервале от [0.25..1] миллисекунды.
GM>3. Потеря даже одной команды списания баланса невозможна.


GM>Предположения
GM>--------------
GM>1. В память одного компа все не влезет. Фактически речь идет об необходимости распределенной in-memory DB.
GM>2. Необходима горячая замена серверов в кластере.
GM>3. Все команды по получению, предварительно писать на диск, или передавать на другой сервер.


Похоже на систему обработки биржевых данных с небольшими нюансами. У нас она решается парой серверов с базой данных kdb+. Начальные условия похожи — более 200 миллионов сообщений в день (в основном за 8 часов работы биржи), в США так даже уже под миллиард сообщений (если считать не только трейды/квоуты но и служебные). Все данные обязательно сохраняются на диск по мере поступления, это довольно стандартный прием, поскольку в случае каких-либо проблем их надо уметь восстановить. Данные, конечно, хранятся в памяти и ничего особенного в базе данных на 200 миллионов не вижу, проблема решается установкой сервера помощнее. Разница в том — что нужно апдейтить баланс, а не добавлять новые данные в конец базы данных. Я сейчас попробовал — апдейт для таблицы с миллионом элементов работает со скоростью 1000 апдейтов за 5 миллисекунд, т.е. достаточно быстро. Задача распределения нагрузки решается достаточно просто средствами самого kdb+, проблема отказа — установкой дублирующих серверов. В общем, задача кажется в чем-то даже более простой, поскольку мы эти данные еще и клиентам предоставляем, которые исполняют достаточно сложные запросы, т.е. большую часть времени сервер занят ими.
Но на все это счастье требуется Бабло и на сам Kdb+ и на серверы. Хотя, опять же, вам, например, не надо столько места на диске сколько нам (для хранения данных за несколько лет), т.е. экономия.

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

GM>А если не 64 битный? Я правда еще не считал разницу в стоимости хранении одного клиента, при использовании 32 или 64 битных серверов. Попробую узнать во сколько обходится хранение 1 млн клиентов. То есть все таки использовать Мнезию предлагаете? Хотя бы начать строить прототип с ее использованием? А вот такой вопрос тогда. В любом случае, информацию нужно регулярно скидывать на диск, хотя бы раз в биллинговый период. Это средствами мнезии ведь тоже возможно?
GM>Упс, сорри моя опечатка: от 0.25 до 1 секунды.

Что-то у вас запросы совсем несерьезные, чувствую, что и Эрланга вполне достаточно.

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

GM>А если не 64 битный? Я правда еще не считал разницу в стоимости хранении одного клиента, при использовании 32 или 64 битных серверов. Попробую узнать во сколько обходится хранение 1 млн клиентов.

Да, лучше наверное начать с этого.

GM>То есть все таки использовать Мнезию предлагаете? Хотя бы начать строить прототип с ее использованием?

Прототип на базе Мнезии для этой задачи сделать должно быть очень просто. Сложно — выжать из него требуюмую производительность, придется как следует постараться, и не факт что получится. Но учитывая, что прототип собирается очень быстро, я бы — попробовал.

В случае неудачи — я бы стал пробовать сделать свое распределенное хранилище на базе ets.

GM>А вот такой вопрос тогда. В любом случае, информацию нужно регулярно скидывать на диск, хотя бы раз в биллинговый период. Это средствами мнезии ведь тоже возможно?

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

G>>А вот насчет задержки обработки отдельного сообщения до 1 миллисекунды — я совсем не уверен, сможет ли Эрланг такое дать. Это вообще гарантировать тяжело, учитывая задержки в TCP/IP, и размер кванта оперсистемы в 10-15 msec.

GM>Упс, сорри моя опечатка: от 0.25 до 1 секунды.

А, ну это должно получиться без проблем.

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

Q>Данные, конечно, хранятся в памяти и ничего особенного в базе данных на 200 миллионов не вижу, проблема решается установкой сервера помощнее.

А применро что подразумевается под "сервером помощнее" для задачи такого размера под управлением kdb+ ? Я конечно понимаю, что все depends. Но хотя бы плюс-минус трамвайная остановка.

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

GM>2. Скорость обработки одного запроса в интервале от [0.25..1] миллисекунды.
GM>3. Потеря даже одной команды списания баланса невозможна.
. . . .
GM>3. Все команды по получению, предварительно писать на диск, или передавать на другой сервер.

А как можно физически за это время что-то там успеть записать на диск, если даже у самых быстрых и хороших дисков seek time — порядка 5 миллисекунд?

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

Pzz>Здравствуйте, Gerasim.mu, Вы писали:

GM>>2. Скорость обработки одного запроса в интервале от [0.25..1] миллисекунды.
GM>>3. Потеря даже одной команды списания баланса невозможна.
Pzz> . . . .
GM>>3. Все команды по получению, предварительно писать на диск, или передавать на другой сервер.

Pzz>А как можно физически за это время что-то там успеть записать на диск, если даже у самых быстрых и хороших дисков seek time — порядка 5 миллисекунд?

Я предполагал:
1. Команды на изменение баланса приходят в асинхронном режиме. То есть, с момента приема команды, проблема обеспечения консистентности и надежности — проблема разрабатываемой системы.
2. Серверов будет в любом случае больше одного и винтов можно использовать несколько (тут тоже распараллеливать). В Oracle похожий механизм это Redo файлы.

Сохранение предполагается для восстановления при сбое. Как вариант рассматривается передача данного сообщения на другой сервер, что бы он там в памяти хранился (опять таки аналог Oracle StandBy только не файлами а сообщениями по сети). Но как вы уже заметили, сложно выйти за круг своих знаний по C++. нужно образ мышления менять

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

M>А применро что подразумевается под "сервером помощнее" для задачи такого размера под управлением kdb+ ? Я конечно понимаю, что все depends. Но хотя бы плюс-минус трамвайная остановка.

Так в целом ничего особенного — 8 процессоров, 128Г памяти, террабайт 8 диска (если нужно данные долго хранить).

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

GM>Я предполагал:
GM>1. Команды на изменение баланса приходят в асинхронном режиме. То есть, с момента приема команды, проблема обеспечения консистентности и надежности — проблема разрабатываемой системы.
GM>2. Серверов будет в любом случае больше одного и винтов можно использовать несколько (тут тоже распараллеливать). В Oracle похожий механизм это Redo файлы.

Распараллеливание может увеличить скорость линейного чтения/записи и позволить исполнять несколько запросов одновременно (т.е., увеличить количество запросов, которые вы в состоянии выполнить за единицу времени). Однако от seek time вы никуда не денетесь, и каждый отдельный запрос, сколько бы их одновременно не выполнялось, будет ограничен снизу этим временем. Это аналогично тому, что 10 тёток могут родить 10 детей за 9 месяцев, но не могут родить одного ребенка за месяц.

Единственный способ преодолеть это ограничение — это писать все поступающие запросы на диск последовательно — seek будет происходить лишь когда вы дошли до конца дорожки на диске и переходите на следующую, т.е. далеко не на каждый запрос. Но это очень не похоже на то, что делают с дисками базы данных.

Кроме того, даже при последовательной записи не так-то просто понять, когда данные уже точно оказались на диске, потому что их буферизует и операционная система и диск, а если вы выключите эту буферизацию, вы будете писать по сектору за раз, с интервалами порядка времени оборота диска. В UNIX'е узнать это по-моему вообще невозможно из user space (кроме как ценой сказать fsync() на файл и дождаться, когда все буферизованные данные окажутся на диске, но это займет больше 1 миллисекунды). В венде теоретически возможно, используя overlapped i/o, но работает ли это на практике, я не уверен, и ответ на этот вопрос из документации не выводится.

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

GM>Сохранение предполагается для восстановления при сбое. Как вариант рассматривается передача данного сообщения на другой сервер, что бы он там в памяти хранился (опять таки аналог Oracle StandBy только не файлами а сообщениями по сети). Но как вы уже заметили, сложно выйти за круг своих знаний по C++. нужно образ мышления менять

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

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

Pzz>Единственный способ преодолеть это ограничение — это писать все поступающие запросы на диск последовательно — seek будет происходить лишь когда вы дошли до конца дорожки на диске и переходите на следующую, т.е. далеко не на каждый запрос. Но это очень не похоже на то, что делают с дисками базы данных.
Вариант решения аппаратный: для redo-диска взять SDD. Время поиска меньше миллисекунды.

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

Pzz>>Единственный способ преодолеть это ограничение — это писать все поступающие запросы на диск последовательно — seek будет происходить лишь когда вы дошли до конца дорожки на диске и переходите на следующую, т.е. далеко не на каждый запрос. Но это очень не похоже на то, что делают с дисками базы данных.
C>Вариант решения аппаратный: для redo-диска взять SDD. Время поиска меньше миллисекунды.

Можно, да. Но они маленькие, дорогие, и в них при интенсивном использовании протираются дырки. Зато время доступа predictable, в отличии от механического диска.

Можно еще просто RAM взять с автономным питанием — наверняка в природе существует такое железо с дисковым интерфейсом.

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

Pzz>Можно, да. Но они маленькие, дорогие, и в них при интенсивном использовании протираются дырки. Зато время доступа predictable, в отличии от механического диска.
1) Для redo-диска много места не надо.
2) Уже не дорогие. Одна модель на 128GB стоит $550.
3) Дырки уже давно не протираются, это сказки.

Pzz>Можно еще просто RAM взять с автономным питанием — наверняка в природе существует такое железо с дисковым интерфейсом.
Есть.

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

C>2) Уже не дорогие. Одна модель на 128GB стоит $550.

Ух ты! 128G за $550 — это очень соблазнительная цена.

C>3) Дырки уже давно не протираются, это сказки.

А сколько циклов записи выдерживают современные флешки?

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

C>>2) Уже не дорогие. Одна модель на 128GB стоит $550.
Pzz>Ух ты! 128G за $550 — это очень соблазнительная цена.
Ага. Я себе купил, сейчас сижу и радуюсь.

C>>3) Дырки уже давно не протираются, это сказки.
Pzz>А сколько циклов записи выдерживают современные флешки?
Около 500000 на ячейку. Но это не важно, так как там микроконтроллер делает аппаратный wear levelling. При постоянной записи 24x7 срок службы более 5 лет.

Pzz>>Можно еще просто RAM взять с автономным питанием — наверняка в природе существует такое железо с дисковым интерфейсом.
C>Есть.

Да есть такая штука. Но она увеличивает стоимость "одной транзакции" и "стоимость хранения одной записи".
А по поводу последовательной записи — да, я согласен. Скорость будет выше.

Просто как вариант, я рассматриваю следующий вариант:
передача сообщений идет сквозь несколько серверов, на промежуточном сервере она хранится только в ОЗУ, а запись на диск идет только на последнем.

client->Server1->Server2->Server3 (запись на HDD только тут)

P.S.
углубляюсь в эранг, может есть решение изящней.