Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8 9   вперед  Ctrl      все
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
VoltDB
Member

Откуда: Chicago, USA
Сообщений: 158
Капитан очевидность на проводе

Разработчики средств вроде mysql - они генералисты, они пишут обобщенные решения которые должны удовлетворить всех.
Для них сама мысль о том, что конечного пользователя их продукта нужно ограничить и заставить ходить строго по заданным правилам - она крамольна по сути.

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

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


А еще можно свой оптимизатор запросов на стороне сервера приложений написать. Это чтоб если РНР коду данные из двух нодов могут понадобиться... Или больше... Мало ли, может в запросе кроме голого SELECTа еще и суб-запрос есть... Ну или, недай бог, JOIN какой...

А еще, можно вообще все данные на сервере приложений хранить. Например, в текстовом файле... Нету СУБД - так и разбираться не некому, куда за данными ходить...

Другой вопрос в том, что таких людей, которые понимают как надо - их еще поискать...

Золотые слова...
6 янв 14, 23:01    [15382739]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
VoltDB
Member

Откуда: Chicago, USA
Сообщений: 158
vromanov
вавп,

Читаю на странице 30-day trial download.
"If you already have the VoltDB Trial Version and are looking for tools or a client kit, see our Client Software Kits for popular programming languages"


"...Download options include Linux Enterprise and Open Source kits as well as Mac Developer kits and client libraries and tools..."
7 янв 14, 00:03    [15382978]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
vromanov
Member

Откуда: СПб
Сообщений: 345
VoltDB,
автор
Как клиент-приложение принимает решение на какой узел посылать запрос, содержащий JOIN?

Там это происход не на уровне SQL, а на другом уровне (C Api)
7 янв 14, 00:44    [15383065]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
VoltDB
Member

Откуда: Chicago, USA
Сообщений: 158
vromanov
VoltDB,
автор
Как клиент-приложение принимает решение на какой узел посылать запрос, содержащий JOIN?

Там это происход не на уровне SQL, а на другом уровне (C Api)


Если речь идет о приложении-клиенте, которое выбирает на какой узел распределенной СУБД посылать SQL запросы в зависимости от того, как партицированы данных, то я не совсем понял ответ. Вы не могли бы пояснить?
7 янв 14, 02:34    [15383264]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
dbms_photoshop
Member

Откуда: sqlmdx.net
Сообщений: 5151
VoltDB
Более короткий ответ на Ваш вопрос, это то что если структура бизнес-данных меняется, но при этом не изменяет фундаментально самого бизнеса-процесса, это не требует кардинальных изменений в распределении данных на кластере.
Ок, переформулирую боле конкретно.
Пусть большая часть запросов обращалась к таблицам, которые были в отношении многие к 1, а потом стали многие ко многим.
Например, изначально в системе закладывалось, что у апартаментов может быть один владелец, потом стало возможно что это группа лиц.
С точки зрения заказчика здесь нет изменения, требующего кардинальной перестройки системы. И в грамотно спроектированном приложении на Оракл, это несложно изменить.

Касательно voltdb, в этом случае, транзацкии, которые были single-sited перестают быть таковыми, что может кардинально повлиять на производительность. Так ли это?
7 янв 14, 04:20    [15383324]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
dbms_photoshop
Member

Откуда: sqlmdx.net
Сообщений: 5151
VoltDB
Вы абсолютно правы в том, что DW, как правило, имеет более одной факт-таблицы. Не уверен в чем вопрос - я не увидел противоречия в цитате на которую Вы ссылаетесь, а именно что 100% всех схем являются или старами или снежинками, содержащими центральную таблицу с фактами с 1-n связями с измерениями итд. Может, быть, разночтения есть далее в контексте статьи?
В моем понимании, если факт 1, то схема может быть tree, а когда их несколько, то это уже non-tree schema в терминологии статьи.
С соответствующей разницей в производительности.
7 янв 14, 04:24    [15383326]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
VoltDB
Member

Откуда: Chicago, USA
Сообщений: 158
dbms_photoshop
VoltDB
Более короткий ответ на Ваш вопрос, это то что если структура бизнес-данных меняется, но при этом не изменяет фундаментально самого бизнеса-процесса, это не требует кардинальных изменений в распределении данных на кластере.
Ок, переформулирую боле конкретно.
Пусть большая часть запросов обращалась к таблицам, которые были в отношении многие к 1, а потом стали многие ко многим.
Например, изначально в системе закладывалось, что у апартаментов может быть один владелец, потом стало возможно что это группа лиц.
С точки зрения заказчика здесь нет изменения, требующего кардинальной перестройки системы. И в грамотно спроектированном приложении на Оракл, это несложно изменить.

Касательно voltdb, в этом случае, транзацкии, которые были single-sited перестают быть таковыми, что может кардинально повлиять на производительность. Так ли это?


Да, при изменении single-sited на multi-sited, разница в производительности будет существенной; но даже multi-sited намного быстрее традиционной реляционной системы. И по аналогии с Вашим примером, в любой грамотно спроектированой базе, процесс изменения схемы достаточно тривиальный, за исключением баз с большим количеством данных (каковыми подавляющее большинство OLTP не являются). У меня нет точных статистических данных, но я бы очень удивился, если бы оказалось, что больше 10% всех OLTP баз данных в мире превышают размером 1 TB (скорее даже гораздо меньше). При таких небольших объемах, перепартиционирование на кластере - дело не занимающее много времени. Простой расчет: давайте предположим что кластер сидит на стандартной 1ГигЕ сетке с соответствующим дешевым свичем. Это 125МВ/сек минус TCP издержки - пускай чистыми 100МВ/сек. Скажем, Ваша база 600ГВ и распределена на 5-узловом кластере. Значит нужно прочитать и потом записать из памяти одного нода в память другого в общей сложности 600ГВ данных, параллельно используя 5 сетевых интерфейсов с пропускной способностью 100МВ/сек каждый. То есть, полностью перепарционировать 600ГВ база займет около 20 минут. В реальности, я думаю что на сопоставимое изменение схемы в традиционной дисковой СУБД может уйти больше времени - ведь в нашем с вами примере "узкое место" - это сеть, а в случае с дисковое СУБД это будет диск. Кстати, я ведь посчитал самую обычную 1ГигЕ сетку - в реальности-то у Вас на кластере, наверное, по-сильнее.
7 янв 14, 05:44    [15383343]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
VoltDB
Member

Откуда: Chicago, USA
Сообщений: 158
VoltDB
dbms_photoshop
пропущено...
Ок, переформулирую боле конкретно.
Пусть большая часть запросов обращалась к таблицам, которые были в отношении многие к 1, а потом стали многие ко многим.
Например, изначально в системе закладывалось, что у апартаментов может быть один владелец, потом стало возможно что это группа лиц.
С точки зрения заказчика здесь нет изменения, требующего кардинальной перестройки системы. И в грамотно спроектированном приложении на Оракл, это несложно изменить.

Касательно voltdb, в этом случае, транзацкии, которые были single-sited перестают быть таковыми, что может кардинально повлиять на производительность. Так ли это?


Да, при изменении single-sited на multi-sited, разница в производительности будет существенной; но даже multi-sited намного быстрее традиционной реляционной системы. И по аналогии с Вашим примером, в любой грамотно спроектированой базе, процесс изменения схемы достаточно тривиальный, за исключением баз с большим количеством данных (каковыми подавляющее большинство OLTP не являются). У меня нет точных статистических данных, но я бы очень удивился, если бы оказалось, что больше 10% всех OLTP баз данных в мире превышают размером 1 TB (скорее даже гораздо меньше). При таких небольших объемах, перепартиционирование на кластере - дело не занимающее много времени. Простой расчет: давайте предположим что кластер сидит на стандартной 1ГигЕ сетке с соответствующим дешевым свичем. Это 125МВ/сек минус TCP издержки - пускай чистыми 100МВ/сек. Скажем, Ваша база 600ГВ и распределена на 5-узловом кластере. Значит нужно прочитать и потом записать из памяти одного нода в память другого в общей сложности 600ГВ данных, параллельно используя 5 сетевых интерфейсов с пропускной способностью 100МВ/сек каждый. То есть, полностью перепарционировать 600ГВ база займет около 20 минут. В реальности, я думаю что на сопоставимое изменение схемы в традиционной дисковой СУБД может уйти больше времени - ведь в нашем с вами примере "узкое место" - это сеть, а в случае с дисковое СУБД это будет диск. Кстати, я ведь посчитал самую обычную 1ГигЕ сетку - в реальности-то у Вас на кластере, наверное, по-сильнее.


Конечно, имеется ввиду, базы которые превышают 1ТВ каждая.
7 янв 14, 05:51    [15383347]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18486
А мне вот, как неспециалисту, совершенно непонятно, как SN можно приложить к тому же банковскому бизнесу, я уже молчу о карточном

Хоть КОнП нам и утверждает, что в сбере все недоучки и берут количеством за счет качества, но вот реально не могу догнать:
Конец месяца, клиенты ломанулись платить коммуналку. Тысячами. Клиентов разбрасываем по независимым нодам -- легко. Куда мы разбросим контору -- получателя платежей? И вот и блокировки, и точка сериализации и т.д.

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

С карточками все еще сложней -- тут критерии разделения вообще непонятны
7 янв 14, 06:17    [15383361]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
Капитан очевидность на проводе
Guest
Вячеслав Любомудров
А мне вот, как неспециалисту, совершенно непонятно, как SN можно приложить к тому же банковскому бизнесу, я уже молчу о карточном

Хоть КОнП нам и утверждает, что в сбере все недоучки и берут количеством за счет качества, но вот реально не могу догнать:
Конец месяца, клиенты ломанулись платить коммуналку. Тысячами. Клиентов разбрасываем по независимым нодам -- легко. Куда мы разбросим контору -- получателя платежей?


Что значит куда контору? Она что, контора, одна на всю страну? Даже сейчас эти самые ЕРКЦ строго по районам города Москвы, у каждого даже свой отдельный расчетный счет. Это раз. Два - число этих контор конечно, измеряется не триллионами миллионов, а несчастными сотнями тысяч, и ничто не мешает натолкать реквизиты их счетов в каждую ноду - все отлично влезет даже в четыре гектара оперативы (4гигабайта, по пол килобайта на получателя - имеем 8 мульенов получателей просто вот в buffer cache, во всей стране юрлиц и того меньше).

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


И в чем проблема этого взаимодействия, если не секрет? Может стоит рассказать о том, что деньги за платежи коммунальных и прочих услуг - они в коммунальную контору попадают не в режиме realtime, а сначала в банке в АРМ Касса аккумулируются, а потом в конце дня проводятся всего одной проводкой с отдельно приложенным реестром?

Гы, вроде взрослые люди, а таких простых истин не знаете, забавно.

Вячеслав Любомудров
С карточками все еще сложней -- тут критерии разделения вообще непонятны

Еще раз, для тех которые особо не понятливые.

В РФ уже сейчас более 800 разных банков. И ничего, личико у коммунальных предприятий и прочих банкоматов и супермаркетов от такого количества банков как-то не трескается. И что нам мешает тот-же Сбер превратить в Сбер-1, Сбер-2, Сбер-3, Сбер-9000, просто для того, чтоб не покупать один большой и сверхдорогой мегаящик, стоимость обслуживания которого превышает все пределы разумного, и чисто чтоб просто минимизировать риски от отказа и простоя одного большого ящика?

Что мешает на самом деле известно, их подрядчик-разработчик софта не может делать SN, и покупка гробов там диктуется сертификационными требованиями вендора, но тем не менее, в варианте 800 разных банков уже, и что нам мешает запилить еще 400 под одним и тем-же лейблом - не видно никаких проблем (ну кроме того, что софт апгрейдить придется всем 400, по очереди, с помощью чудных .sh скриптов, ну или руками через всякий тул вроде OEM или DBUA, у тех кто поглупее).
7 янв 14, 09:23    [15383421]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
Капитан очевидность на проводе
Guest
VoltDB
Капитан очевидность на проводе
Разработчики средств вроде mysql - они генералисты, они пишут обобщенные решения которые должны удовлетворить всех.
Для них сама мысль о том, что конечного пользователя их продукта нужно ограничить и заставить ходить строго по заданным правилам - она крамольна по сути.

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

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


А еще можно свой оптимизатор запросов на стороне сервера приложений написать. Это чтоб если РНР коду данные из двух нодов могут понадобиться... Или больше... Мало ли, может в запросе кроме голого SELECTа еще и суб-запрос есть... Ну или, недай бог, JOIN какой...



В случае проектов Facebook, Twitter и прочих - подобный вопрос, под названием запросы с джойнами делаются не на сервере БД, а строго и исключительно на сервере приложений - возникает автоматически после наверное уже четвертого физического сервера баз данных (ну не могут реляционные БД больше в кластере, особливо MySQL). Там правда возникают еще и сопутствующие вопросы (как правильно управляться с этими кешами в памяти), но то дело такое.

Стоит понимать, что классическая ACID модель - это обобщение под некие виртуальные гипотетические требования бухгалтерского учета (тут дебет, тут кредит, и ни дай бог чото рассогласуется, или перехлест обновлений остатка по счету пойдет).

А для реальной жизни такие жесткие ACID требования, какие выдвигает/предлагает реляционная СУБД - они обычно и нафиг не нужны, при грамотном дизайне приложения (даже бухгалтерского).


VoltDB
А еще, можно вообще все данные на сервере приложений хранить. Например, в текстовом файле... Нету СУБД - так и разбираться не некому, куда за данными ходить...

И? Они у них так и хранятся, в key-value хранилище. Локальное memcache хранилище, промах в который приводит к походу в MySQL, за... те-же самым key-value. Никакой внутренней структуры value не предусматривается вообще (по причине того, что в MySQL ALTER TABLE отправляет базу данных в долгое бессознательное), только ключ и атомарное значение по нему - строка/число/дата. Одна таблица, две колонки. Первая из которых единственных индекс - красота.

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

А то что тормозит все это нагромождение безбожно (а ну-ка, сходи 200 раз за key-value, чтоб страничку прорисовать), так это просто - всегда можно поставить с миллион серверов в датацентр, деньги то бешеные с рекламы и прочих IPO и так текут, чай не разоримся (те самые 200 запросов SELECT value FROM the_table WHERE key = :key можно делать на 200 разных серверах одновременно, для текущего запроса Васи Пупкина, красота, быстрота!).
7 янв 14, 09:50    [15383429]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18486
Капитан очевидность на проводе
Вячеслав Любомудров
А мне вот, как неспециалисту, совершенно непонятно, как SN можно приложить к тому же банковскому бизнесу, я уже молчу о карточном

Хоть КОнП нам и утверждает, что в сбере все недоучки и берут количеством за счет качества, но вот реально не могу догнать:
Конец месяца, клиенты ломанулись платить коммуналку. Тысячами. Клиентов разбрасываем по независимым нодам -- легко. Куда мы разбросим контору -- получателя платежей?


Что значит куда контору? Она что, контора, одна на всю страну? Даже сейчас эти самые ЕРКЦ строго по районам города Москвы, у каждого даже свой отдельный расчетный счет. Это раз. Два - число этих контор конечно, измеряется не триллионами миллионов, а несчастными сотнями тысяч, и ничто не мешает натолкать реквизиты их счетов в каждую ноду - все отлично влезет даже в четыре гектара оперативы (4гигабайта, по пол килобайта на получателя - имеем 8 мульенов получателей просто вот в buffer cache, во всей стране юрлиц и того меньше).
Допустим
Но ведь в конце концов все это должно где-то осесть, на родной ноде этой конторы, а это синхронизация в реальном времени, как минимум
И дело даже не в реквизитах этих контор-получателей. Нужно иметь оперативный доступ к состоянию их счета, и иметь возможность провести (и подтвердить) транзакцию. Более того, их нужно будет проводить последовательно, чтоб не потерять изменений от других нод

Тем более это же очень малая часть всей деятельности
Что-то другое туда еще влезет?
Капитан очевидность на проводе
Вячеслав Любомудров
И вот и блокировки, и точка сериализации и т.д.
Я уж не говорю о более других счетах, которые взаимодействуют практически с каждым клиентом


И в чем проблема этого взаимодействия, если не секрет? Может стоит рассказать о том, что деньги за платежи коммунальных и прочих услуг - они в коммунальную контору попадают не в режиме realtime, а сначала в банке в АРМ Касса аккумулируются, а потом в конце дня проводятся всего одной проводкой с отдельно приложенным реестром?
Далеко не всегда и не везде
Я не знаю, как это в сбере делается, но даже с такой раскладкой, на счета контор-получателей деньги не только приходят, их еще и тратят, т.е. как правило нужно всегда знать текущий оперативный остаток
Аккумулятор АРМа Касса это конечно здорово, но ведь нужна еще и надежность

А расчет процентов, например. Или взятие комиссий и т.д. Конкретный счет корреспондирует с миллионами клиентских...
Капитан очевидность на проводе
Вячеслав Любомудров
С карточками все еще сложней -- тут критерии разделения вообще непонятны

Еще раз, для тех которые особо не понятливые.

В РФ уже сейчас более 800 разных банков. И ничего, личико у коммунальных предприятий и прочих банкоматов и супермаркетов от такого количества банков как-то не трескается. И что нам мешает тот-же Сбер превратить в Сбер-1, Сбер-2, Сбер-3, Сбер-9000, просто для того, чтоб не покупать один большой и сверхдорогой мегаящик, стоимость обслуживания которого превышает все пределы разумного, и чисто чтоб просто минимизировать риски от отказа и простоя одного большого ящика?

Что мешает на самом деле известно, их подрядчик-разработчик софта не может делать SN, и покупка гробов там диктуется сертификационными требованиями вендора, но тем не менее, в варианте 800 разных банков уже, и что нам мешает запилить еще 400 под одним и тем-же лейблом - не видно никаких проблем (ну кроме того, что софт апгрейдить придется всем 400, по очереди, с помощью чудных .sh скриптов, ну или руками через всякий тул вроде OEM или DBUA, у тех кто поглупее).
Не проблема
Но насколько возможно обеспечить надежность и отчетность в реальном времени на определенную дату?
Видится мне, что реализация всего этого будет намного сложнее (и дороже) чем пара больших ящиков и шкафов с дисковыми полками

Ну вот, хоть убейте, не могу тут найти место для SN
На мой взгляд, туда могут подойти задачи, где данные достаточно независимые (например, всякие социальные сети, интернет-магазины) или где не нужна особая достоверность и надежность (например, поисковые системы).
Возможно, я не прав
7 янв 14, 10:06    [15383440]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
Областной ЛТП
Guest
VoltDB
Это 125МВ/сек минус TCP издержки - пускай чистыми 100МВ/сек. Скажем, Ваша база 600ГВ и распределена на 5-узловом кластере. Значит нужно прочитать и потом записать из памяти одного нода в память другого в общей сложности 600ГВ данных, параллельно используя 5 сетевых интерфейсов с пропускной способностью 100МВ/сек каждый. То есть, полностью перепарционировать 600ГВ база займет около 20 минут.
Ноды с дисками 200МБ/с случайного чтения+записи, пятью сетевыми картами, терабайтом оперативки и соответствущей шиной. Недшевенький кластерок получается с масштабируемостью до всего-то 5+1 нод.
7 янв 14, 14:44    [15383796]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
Капитан очевидность на проводе
Guest
Вячеслав Любомудров
А расчет процентов, например. Или взятие комиссий и т.д. Конкретный счет корреспондирует с миллионами клиентских...

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

Миф про миллионы операций в день как-то сразу треснет.

А по поводу в реальном режиме времени корреспонденций - еще раз, в РФ существуют уже 800 банков с сотнями отделелний. Они что, все дружно реплицируют данные между своими серверами Oracle в реальном режиме времени и с полной чисто оракловской транзакционной консистентностью? Или все-же используют некие специальные протоколы, вроде S.W.I.F.T.?


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

Нет, не будет дороже. Но любую идею можно довести до абсурда. К примеру вызывать на обновление ПО специалистов из США для каждого сервера в отдельности (с оплатой гостинниц и самолетов как это происходит сейчас), естественно затраты растут прямо пропорционально количеству этих SN независимых нод.

А можно освоить режим пакетного обновления, тогда затраты будут такие-же, а то и ниже. И т.д. Это все зависит от воли руководства к победе.


Вячеслав Любомудров
Ну вот, хоть убейте, не могу тут найти место для SN
На мой взгляд, туда могут подойти задачи, где данные достаточно независимые (например, всякие социальные сети, интернет-магазины) или где не нужна особая достоверность и надежность (например, поисковые системы).
Возможно, я не прав


Еще раз. Вот есть банк, у него миллионы физических лиц, которые НИКОГДА не корреспондируют между собой. Да никогда Иванов не отправляет деньги Сидорову. Что не так?

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


shared nothing это не понижение достоверности и надежности, откуда такое упадничество? SN - это лишь про разукрупнение внутренней связности, частно избыточной и неоправданной. Если в одном мегабольшом ящике обеспечивается транзакционная консистентность, то этими-же средствами она обеспечивается и SN кластере, ибо деление происходит на прикладном, а не на системном уровне, в чем проблема-то? Не знаете как делать двухфазные фиксации? Научим!
7 янв 14, 15:59    [15383964]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
Ох уж эти банки
Guest
Капитан очевидность на проводе
Еще раз. Вот есть банк, у него миллионы физических лиц, которые НИКОГДА не корреспондируют между собой. Да никогда Иванов не отправляет деньги Сидорову. Что не так?


А что если вдруг отправит? А что если в изначальном ТЗ такие ситуации были исключены, а потом бизнес потребовал?
7 янв 14, 16:21    [15384007]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
dbms_photoshop
Member

Откуда: sqlmdx.net
Сообщений: 5151
VoltDB
То есть, полностью перепарционировать 600ГВ база займет около 20 минут.
Допустим это так, только вот изменение настолько ключевое, что потребуется регрессионное тестирование всей системы.
И долгие разговоры с начальством про выделение ресурсов на это.
А в реальной практиве подобные изменений далеко не редкость.
7 янв 14, 16:58    [15384087]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18486
Капитан очевидность на проводе
Вячеслав Любомудров
А расчет процентов, например. Или взятие комиссий и т.д. Конкретный счет корреспондирует с миллионами клиентских...

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

Миф про миллионы операций в день как-то сразу треснет.
Мы ведь начинали со сбера
Пусть не миллионы, но сотни-десятки тысяч по одному счету -- это вполне реальность
Капитан очевидность на проводе
А по поводу в реальном режиме времени корреспонденций - еще раз, в РФ существуют уже 800 банков с сотнями отделелний. Они что, все дружно реплицируют данные между своими серверами Oracle в реальном режиме времени и с полной чисто оракловской транзакционной консистентностью? Или все-же используют некие специальные протоколы, вроде S.W.I.F.T.?
Им не нужно реплицироваться между собой, это вполне себе разные системы и задержка там вполне допустима
Но, например, внутри одного банка между отделениями задержка уже более критична
Да дело тут и не в задержке, а просто в достоверности данных. Чтоб клиент не добрался между отделениями быстрее, чем дошла информация о других его платежах (если, конечно, банк декларирует услугу обслуживания в любом отделении)
Капитан очевидность на проводе
Вячеслав Любомудров
Не проблема
Но насколько возможно обеспечить надежность и отчетность в реальном времени на определенную дату?
Видится мне, что реализация всего этого будет намного сложнее (и дороже) чем пара больших ящиков и шкафов с дисковыми полками

Нет, не будет дороже. Но любую идею можно довести до абсурда. К примеру вызывать на обновление ПО специалистов из США для каждого сервера в отдельности (с оплатой гостинниц и самолетов как это происходит сейчас), естественно затраты растут прямо пропорционально количеству этих SN независимых нод.

А можно освоить режим пакетного обновления, тогда затраты будут такие-же, а то и ниже. И т.д. Это все зависит от воли руководства к победе.
До абсурда можно довести все, что угодно
Но какое это имеет отношение к разнице между SN и простым тупым большим шкафом?
Капитан очевидность на проводе
Вячеслав Любомудров
Ну вот, хоть убейте, не могу тут найти место для SN
На мой взгляд, туда могут подойти задачи, где данные достаточно независимые (например, всякие социальные сети, интернет-магазины) или где не нужна особая достоверность и надежность (например, поисковые системы).
Возможно, я не прав


Еще раз. Вот есть банк, у него миллионы физических лиц, которые НИКОГДА не корреспондируют между собой. Да никогда Иванов не отправляет деньги Сидорову. Что не так?
Но среди них может ведь попасться и пару (тысяч) засранцев
Например, у нас банк предоставляет перевод с одной зарплатной карты на чужую (денег до аванса перехватил, и отдал, чтоб не наличкой)
Люди пользуются
Причем, я уверен, что это производится через какой-нибудь (общий для всех) транзитный счет
Капитан очевидность на проводе
Вячеслав Любомудров
или где не нужна особая достоверность и надежность (например, поисковые системы).
Возможно, я не прав


shared nothing это не понижение достоверности и надежности, откуда такое упадничество? SN - это лишь про разукрупнение внутренней связности, частно избыточной и неоправданной. Если в одном мегабольшом ящике обеспечивается транзакционная консистентность, то этими-же средствами она обеспечивается и SN кластере, ибо деление происходит на прикладном, а не на системном уровне, в чем проблема-то? Не знаете как делать двухфазные фиксации? Научим!
Все понятно, но в некоторых случаях эта модель становится намного сложнее классической
Стоит ли тогда огород городить?
7 янв 14, 17:50    [15384192]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
Капитан очевидность на проводе
Guest
Ох уж эти банки
Капитан очевидность на проводе
Еще раз. Вот есть банк, у него миллионы физических лиц, которые НИКОГДА не корреспондируют между собой. Да никогда Иванов не отправляет деньги Сидорову. Что не так?


А что если вдруг отправит? А что если в изначальном ТЗ такие ситуации были исключены, а потом бизнес потребовал?


Если отправит - тогда пойдет "свифтовка" - операция будет отражена на двух нодах одновременно (у получателя и отправителя), эдакой двухфазной транзакцией (прикладного уровня,а не Oracle 2PC) как это делается при межбанковском переводе. В чем вопрос-то?

Да, такие операции относительно "дороги" в части требуемых аппаратных ресурсов, но если их доля составляет менее 1% (а там сильно меньше), то потерями в производительности (в сравнении с "все крутится в одном ящике") просто можно пренебречь.
7 янв 14, 17:51    [15384193]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
Капитан очевидность на проводе
Guest
Вячеслав Любомудров
Пусть не миллионы, но сотни-десятки тысяч по одному счету -- это вполне реальность

Вполне реальность что даже у крупных предприятий выписка по банку - это от силы пара сотен записей в день. Вот это вполне реальность.


Вячеслав Любомудров
Капитан очевидность на проводе
А по поводу в реальном режиме времени корреспонденций - еще раз, в РФ существуют уже 800 банков с сотнями отделелний. Они что, все дружно реплицируют данные между своими серверами Oracle в реальном режиме времени и с полной чисто оракловской транзакционной консистентностью? Или все-же используют некие специальные протоколы, вроде S.W.I.F.T.?
Им не нужно реплицироваться между собой, это вполне себе разные системы и задержка там вполне допустима

Так и между виртуальными банками не нужно реплицироваться, и там тоже вполне допустима задержка (измеряемая в секундах, ну пусть даже и минутах).

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


Вячеслав Любомудров
Но, например, внутри одного банка между отделениями задержка уже более критична

Насколько критична? В чем измеряется критичность? Где пороговая величина, которая говорит о "все пропало"?

Вячеслав Любомудров
Да дело тут и не в задержке, а просто в достоверности данных. Чтоб клиент не добрался между отделениями быстрее, чем дошла информация о других его платежах (если, конечно, банк декларирует услугу обслуживания в любом отделении)

Что такое достоверность? В моем понимании это просто разрушенные данные - захожу через сайт - данные одни, зашел толстым клиентом - данные совсем другие - НЕ ДОСТОВЕРНО!

А тут о чем речь, куда там кто должен добраться? Не понятно.


Вячеслав Любомудров
Капитан очевидность на проводе
пропущено...

Нет, не будет дороже. Но любую идею можно довести до абсурда. К примеру вызывать на обновление ПО специалистов из США для каждого сервера в отдельности (с оплатой гостинниц и самолетов как это происходит сейчас), естественно затраты растут прямо пропорционально количеству этих SN независимых нод.

А можно освоить режим пакетного обновления, тогда затраты будут такие-же, а то и ниже. И т.д. Это все зависит от воли руководства к победе.
До абсурда можно довести все, что угодно
Но какое это имеет отношение к разнице между SN и простым тупым большим шкафом?

Непосредственно и имеет. Стоимость владения состоит не только из стоимости шкафа и стоимости лицензий на ПО в нем.
Есть еще и эксплуатационные расходы, которые многократно превышают стоимость шкафов.

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

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

Вячеслав Любомудров
Все понятно, но в некоторых случаях эта модель становится намного сложнее классической
Стоит ли тогда огород городить?


Да, стоит. Варианты

"мы обосрались с настройкой сториджа и ВСЯ страна (50% населения) не может производить покупки в супермаркетах и т.п."
"мы обосрались с настройкой сториджа но лишь 0.5% населения не может производить покупки в супермаркетах и т.п."

есть некая разница в цифрах.

проблемы у 0.5% населения можно списать на козни местных интернет провайдеров, а вот проблемы у ВСЕХ клиентов банка из-за того, что там ВНЕЗАПНО запустилась дефрагментация на хитаче сторидже - это однозначно идиотизм IT руководства банка.

Аналогично, мы тут все не девочки, и прекрасно понимаем, что огромная часть проблем вылавливается уже после запуска в продакшин. Так вот проще свежие версии выпустить сначала для 0.5% населения, и только потом уже выкатывать оставшимся 99.5%, когда будут зачинены невыловленные в UAT проблемы, так "мы обосрались" фактор будет менее болезненно бить по ни в чем не повинным клиентам, разве это не очевидно?

Вообще странно, что приходится разжевывать такие прописные и вроде вполне очевидные истины. Видно никто тут теорию отказов и теорию массового обслуживания толком никогда и не изучал? Инженерный персонал, ну да, ну да.
7 янв 14, 18:06    [15384240]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
Капитан очевидность на проводе
Guest
Вячеслав Любомудров
Да дело тут и не в задержке, а просто в достоверности данных. Чтоб клиент не добрался между отделениями быстрее, чем дошла информация о других его платежах (если, конечно, банк декларирует услугу обслуживания в любом отделении)


Эээээ... Еще раз. Данные клиента всегда хранятся в ОДНОМ И ЗАРАНЕЕ ИЗВЕСТНОМ сервере.
Девушке оперционистке из Урюпинска балансировщиком нагрузки (эдакой обратной проксей) абсолютно одинаково выдается тот-же сервер, что и девушке из Камышина.

Просто программа клиент подключается к балансировщику нагрузки, и он ее перенаправляет на строго нужную и заранее известную физическую ноду. Одну единственную, никаких там round-robin.

Данные клиента при между нодами НЕ кочуют (как это якобы сделано у ОПСОСов), если и кочуют, то только на резервный стендбай.


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

Времена оффлайновых "интернетов" уже прошли, больше никто не держит серверы в самых Камышинах (это повывели несколько лет назад практически повсеместно). Камышинское отделение имеет только сетевой VPN раутер и терминалы у операционисток, все остальное давно уже в датацентрах.
7 янв 14, 18:18    [15384263]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
Капитан очевидность на проводе
Guest
Капитан очевидность на проводе
Эээээ... Еще раз. Данные клиента всегда хранятся в ОДНОМ И ЗАРАНЕЕ ИЗВЕСТНОМ сервере.


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

Т.е. есть некая хеш функция, куда мы передаем ID клиента и на выходе получаем ID сервера (из множества имеющихся), к которому он, клиент, заранее жестко привязан.

А то не дай бог кому сейчас померещится что вообще все клиенты ходят строго в одну ноду, а остальные ноды там просто так, для резерва, или вообще без дела прохлаждаются.
7 янв 14, 18:24    [15384273]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
Ох уж эти банки
Guest
Капитан очевидность на проводе
Ох уж эти банки
пропущено...


А что если вдруг отправит? А что если в изначальном ТЗ такие ситуации были исключены, а потом бизнес потребовал?


Если отправит - тогда пойдет "свифтовка" - операция будет отражена на двух нодах одновременно (у получателя и отправителя), эдакой двухфазной транзакцией (прикладного уровня,а не Oracle 2PC) как это делается при межбанковском переводе. В чем вопрос-то?

Да, такие операции относительно "дороги" в части требуемых аппаратных ресурсов, но если их доля составляет менее 1% (а там сильно меньше), то потерями в производительности (в сравнении с "все крутится в одном ящике") просто можно пренебречь.


Вопрос-то как раз не в дороговизне операций. По данному пункту спора нет. А в сложности их реализации на програмном уровне в условиях распределенной архитектуры. Количество чел\часов высокооплачиваемых менеджеров и архитекторов в банке может бодренько переплюнуть по затратам стоимость одного мега-ящика вкупе с многолетним его обслуживанием.


Капитан очевидность на проводе
Да, стоит. Варианты

"мы обосрались с настройкой сториджа и ВСЯ страна (50% населения) не может производить покупки в супермаркетах и т.п."
"мы обосрались с настройкой сториджа но лишь 0.5% населения не может производить покупки в супермаркетах и т.п."


Не совсем так:

"мы обосрались с настройкой сториджа и ВСЯ страна (50% населения) не смогла какое-то малое время производить покупки в супермаркетах пока не поднялись с бэкапа"
"мы накатили апдейт и у 0.001% населения при переводе денег с зарплатной карты на персональную сумма снимается два раза. Пока выясняли, что и как, юр.отдел завалили претензиями"
7 янв 14, 18:35    [15384298]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18486
Капитан очевидность на проводе
Капитан очевидность на проводе
Эээээ... Еще раз. Данные клиента всегда хранятся в ОДНОМ И ЗАРАНЕЕ ИЗВЕСТНОМ сервере.


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

Т.е. есть некая хеш функция, куда мы передаем ID клиента и на выходе получаем ID сервера (из множества имеющихся), к которому он, клиент, заранее жестко привязан.

А то не дай бог кому сейчас померещится что вообще все клиенты ходят строго в одну ноду, а остальные ноды там просто так, для резерва, или вообще без дела прохлаждаются.
Да нет же, тут никакого недопонимания
Все это прекрасно и очень удобно
Но клиент не живет один, как тот самый конь в вакууме
Он всегда с кем-то взаимодействует
И кто-то будет выступать иногда коллектором платежей -- тот самый ГорВодоКанал. И вот уже точка сериализации
Впрочем, ТМО об этом как раз и говорит

PS. А ведь банковский бизнес приведен только в качестве примера (мы же все знаем, что они все равно воруют)
Возможно, в других отраслях более свои тараканы
7 янв 14, 18:43    [15384314]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
Капитан очевидность на проводе
Guest
Ох уж эти банки
Вопрос-то как раз не в дороговизне операций. По данному пункту спора нет. А в сложности их реализации на програмном уровне в условиях распределенной архитектуры. Количество чел\часов высокооплачиваемых менеджеров и архитекторов в банке может бодренько переплюнуть по затратам стоимость одного мега-ящика вкупе с многолетним его обслуживанием.

Какие еще сложности реализации? Это УЖЕ все реализовано - банк и так может отправить платеж клиенту другого банка, все ПО уже написано. Что им мешает отправлять платежи внутри своих "виртуальных банков"? Да ничего - по сути в справочник отделений банков внести пару сотен записей, вот же проблема.

В общем случае нужно только фронтэнд их АРМ "операционистка" дописать, чтоб мог соединяться с нужной нодой автоматом (строк 14 кода).


Ох уж эти банки
Капитан очевидность на проводе
Да, стоит. Варианты

"мы обосрались с настройкой сториджа и ВСЯ страна (50% населения) не может производить покупки в супермаркетах и т.п."
"мы обосрались с настройкой сториджа но лишь 0.5% населения не может производить покупки в супермаркетах и т.п."


Не совсем так:

"мы обосрались с настройкой сториджа и ВСЯ страна (50% населения) не смогла какое-то малое время производить покупки в супермаркетах пока не поднялись с бэкапа"
"мы накатили апдейт и у 0.001% населения при переводе денег с зарплатной карты на персональную сумма снимается два раза. Пока выясняли, что и как, юр.отдел завалили претензиями"


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

Не в том дело что я тотально недоверяю, но при возможности выбора я никогда выбор в их сторону не сделаю, даже подсознательно. Ибо там системная проблема в мышлении, бъет тотально, не только по времени отказов.
7 янв 14, 19:19    [15384414]     Ответить | Цитировать Сообщить модератору
 Re: voltdb - несколько миллионов транзакций в секунду?!  [new]
Капитан очевидность на проводе
Guest
Вячеслав Любомудров
Но клиент не живет один, как тот самый конь в вакууме
Он всегда с кем-то взаимодействует
И кто-то будет выступать иногда коллектором платежей -- тот самый ГорВодоКанал. И вот уже точка сериализации
Впрочем, ТМО об этом как раз и говорит


Нет там никакой сериализации.

Транзакция фиксируется в ноде клиента - отправить водоканал платеж. Прям так и пишется в одной единственной записи: Отправить от Пупкена в Горводоканал счет такой-то, МФО такое-то такую-то сумму.

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

В это время фоновый джоб на клиентской ноде, идет и смотрит на шину сообщений, не появились ли новые платежи в сторону ВНЕШНИХ (по отношению к ноде) клиентов. Если появились - начинает их отсылать куда ему там надо по банковскому протоколу, SMTP подобному.

Никаких сериализаций нет, никто никому не мешает.

Нода получателя (горводоканала) получает кучу входящих сообщений (они никак не сериализуются и могут валиться многими пачками), потом в какой-то момент начинает их всех пачкой проводить (обновляя остаток у горводоканала ВСЕГО ОДИН РАЗ, в итоге), а не многие миллионы раз.

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

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

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

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

Еще чего на пальцах разжевать, может что не понятно в примере выше?

При том, что вся вот та каша выше - у них УЖЕ реализована (при отправке платежей другим банкам), ничего писать дополнительно не надо.
7 янв 14, 19:39    [15384462]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8 9   вперед  Ctrl      все
Все форумы / Oracle Ответить