powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Плюсы против голого Си, холивар #9
25 сообщений из 228, страница 6 из 10
Плюсы против голого Си, холивар #9
    #37952819
Фотография iv_an_ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
донкихот,

Если все равно с избыточностью копий хранить, то почему бы несколько копий не нарезать по карточкам, а ещё несколько --- по банкоматам? И пусть оптимизатор решает, то ли на одной половине colocation устроить, то ли на другой, то ли распилить какой матерный агрегат вообще по всем копиям всех видов.
...
Рейтинг: 0 / 0
Плюсы против голого Си, холивар #9
    #37952847
донкихотПроясним ситуацпропущено...


Какой глубокомысленный, высококвалифицированный и всеобъемлющий ответ, спасибо!

Но вот конкретно привести пример M:N справочника можно? Название его?
Который ну никак не поддается репликации на 1024 ноды?
Простейший пример, при снятии денег в таблицу пишутся записи ссылающиеся на справочник с карточками и справочник с точками съема денег. С любой карточки можно снять с любого банкомата/магазина/...
Вот вы бы все 3 таблицы по какому ключу их секционировали?


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

Это раз.

Два - ты видать сильно не в курсе, что там никаких M:M и прочих подобных глупостей нет. При транзакции код банкомата просто тупо пишется в таблицу фактов, вместе с данными о принадлежности того банкомата и т.п. (это называется денормализация, дети).

Что тебе с того справочника банкоматов надо? Модель, дата выпуска, инвентарный номер, версия установленного ПО? Да неужели?

В общем ты походу видать совсем не в теме, так, поговорить решил, о чем-то там неведомом?
...
Рейтинг: 0 / 0
Плюсы против голого Си, холивар #9
    #37952861
iv_an_ruдонкихот,

Если все равно с избыточностью копий хранить, то почему бы несколько копий не нарезать по карточкам, а ещё несколько --- по банкоматам? И пусть оптимизатор решает, то ли на одной половине colocation устроить, то ли на другой, то ли распилить какой матерный агрегат вообще по всем копиям всех видов.

Просто гениально, просто. Рукоплескание в студии.

На одной ноде повесить карточки, на другой - банкоматы, и зарядить remote query, со всеми вытекающими сетевыми тормозами и прочими SCN synchronization (в терминах Oracle).

Решение вполне достойно звания Архитектора.

С двух больших букв А
...
Рейтинг: 0 / 0
Плюсы против голого Си, холивар #9
    #37952970
донкихот
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Проясним ситуацдонкихотпропущено...

Простейший пример, при снятии денег в таблицу пишутся записи ссылающиеся на справочник с карточками и справочник с точками съема денег. С любой карточки можно снять с любого банкомата/магазина/...
Вот вы бы все 3 таблицы по какому ключу их секционировали?


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

Это раз.

Два - ты видать сильно не в курсе, что там никаких M:M и прочих подобных глупостей нет. При транзакции код банкомата просто тупо пишется в таблицу фактов, вместе с данными о принадлежности того банкомата и т.п. (это называется денормализация, дети).

Что тебе с того справочника банкоматов надо? Модель, дата выпуска, инвентарный номер, версия установленного ПО? Да неужели?

В общем ты походу видать совсем не в теме, так, поговорить решил, о чем-то там неведомом?
Назовите название системы процессирования карточных транзакций в которой реализовано как вы говорите?
...
Рейтинг: 0 / 0
Плюсы против голого Си, холивар #9
    #37952985
донкихот
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Проясним ситуацдонкихотпропущено...

Простейший пример, при снятии денег в таблицу пишутся записи ссылающиеся на справочник с карточками и справочник с точками съема денег. С любой карточки можно снять с любого банкомата/магазина/...
Вот вы бы все 3 таблицы по какому ключу их секционировали?


Карточка привязана к своей ноде (шарду), а банкоматов по стране всего несколько десятков тысяч, для любого сервера БД это семачки - т.е. можно их (справочники банкоматов) смело прокопировать по нодам.
По карточкам можно ещё совершать покупки, по всему миру, в десятках миллионов магазинов.
...
Рейтинг: 0 / 0
Плюсы против голого Си, холивар #9
    #37953019
донкихотНазовите название системы процессирования карточных транзакций в которой реализовано как вы говорите?

Шардирование в этих системах в явном виде не реализовано вообще. Как минимум в way4 его пока нет.
Потому они и требуют покупать гробы вроде ibm p795
...
Рейтинг: 0 / 0
Плюсы против голого Си, холивар #9
    #37953028
донкихотПроясним ситуацпропущено...



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

Отлично! Ты поведал нам уникальный факт, доселе неведомый прогрессивному человечеству.

И сталобыть эти справочники магазинов в каждый банк сотнями тыщ изменений ежедневно реплицируются, да?
Как много нового узнаешь порой.
...
Рейтинг: 0 / 0
Плюсы против голого Си, холивар #9
    #37953033
донкихот
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
iv_an_ruдонкихот,

Если все равно с избыточностью копий хранить, то почему бы несколько копий не нарезать по карточкам, а ещё несколько --- по банкоматам? И пусть оптимизатор решает, то ли на одной половине colocation устроить, то ли на другой, то ли распилить какой матерный агрегат вообще по всем копиям всех видов.
Тянуть данные с разных серверов для мелких транзакций это большие относительные задержки. По какому ключу нарезать справочники?

Вон "Проясним ситуац" предлагает реплицировать справочники с точками съема, т.к. по его мнению существует только "несколько десятков тысяч" мест в мире где можно снять или оплатить с карточки. Или предлагает денормализацию, чтобы каждый писал в "факты" что захочется, без обращения к справочнику для хотя бы минимальной проверки сразу . Проясним ситуац видимо занимается веб-проектами.
...
Рейтинг: 0 / 0
Плюсы против голого Си, холивар #9
    #37953042
донкихот
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Проясним ситуацдонкихотНазовите название системы процессирования карточных транзакций в которой реализовано как вы говорите?

Шардирование в этих системах в явном виде не реализовано вообще. Как минимум в way4 его пока нет.
Потому они и требуют покупать гробы вроде ibm p795
Ну видите, вы умнее их всех. Лично я горд что общаюсь с вами! :)
...
Рейтинг: 0 / 0
Плюсы против голого Си, холивар #9
    #37953045
донкихотИли предлагает денормализацию, чтобы каждый писал в "факты" что захочется, без обращения к справочнику для хотя бы минимальной проверки сразу . Проясним ситуац видимо занимается веб-проектами.

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

Все эти 3БНФ - это хорошо для студентов, теоретиков и баз данных вида АРМ-Кадры размером с 100MB.
Но при количестве фактов более 10млн в день обычно науступает просветвление.
...
Рейтинг: 0 / 0
Плюсы против голого Си, холивар #9
    #37953069
донкихотПроясним ситуацпропущено...


Шардирование в этих системах в явном виде не реализовано вообще. Как минимум в way4 его пока нет.
Потому они и требуют покупать гробы вроде ibm p795
Ну видите, вы умнее их всех. Лично я горд что общаюсь с вами! :)

Нет, я не умнее. Я лишь указал - что банку ничто не мешает себя представить банком из 32 маленьких подбанков под одним управлением и общим лейблом (у ОПСОСов так и происходит).
И поставить для каждого "подбанка" отдельный, независимый процессинг - тем самым минимизировать масштаб и последствия глобальных
отказов, удешевить затраты на оборудование и ПО (серверы по цене растут совсем нелинейно от мощности).

Сейчас пока известно лишь то, что наши банки так не делают - мелочевке это не актуально, а у крупных еще понимание не
наступило, хотя недавние эпические отказы вроде бы должны были надоумить.
...
Рейтинг: 0 / 0
Плюсы против голого Си, холивар #9
    #37953082
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
On 09/11/2012 04:31 PM, донкихот wrote:

Все кто хотит реально холивара, идите в аналогичтный топик на RSDN.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Плюсы против голого Си, холивар #9
    #37953087
донкихот
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Проясним ситуацдонкихотИли предлагает денормализацию, чтобы каждый писал в "факты" что захочется, без обращения к справочнику для хотя бы минимальной проверки сразу . Проясним ситуац видимо занимается веб-проектами.

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

Все эти 3БНФ - это хорошо для студентов, теоретиков и баз данных вида АРМ-Кадры размером с 100MB.
Но при количестве фактов более 10млн в день обычно науступает просветвление.
В случае банков жертвуют скоростью ради надежности, нельзя чтобы все писали что попало, надо проверять.

Я так понимаю "высоконагруженными базами данных" для OLTP задач и у вас обычно все необходимые данные кэшированы в ОЗУ?
...
Рейтинг: 0 / 0
Плюсы против голого Си, холивар #9
    #37953090
MasterZivOn 09/11/2012 04:31 PM, донкихот wrote:

Все кто хотит реально холивара, идите в аналогичтный топик на RSDN.


Тынц на топик где?

Послать в неопределенность я тоже могу, запросто.
...
Рейтинг: 0 / 0
Плюсы против голого Си, холивар #9
    #37953097
Фотография kosh the best
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
нет, конечно весело реализовать очередную dbm поделку, но не стоит этим особенно гордится, лол
высоконагруженные веб приложения у него, а ха ха
...
Рейтинг: 0 / 0
Плюсы против голого Си, холивар #9
    #37953098
донкихот
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Проясним ситуацдонкихотпропущено...

Ну видите, вы умнее их всех. Лично я горд что общаюсь с вами! :)

Нет, я не умнее. Я лишь указал - что банку ничто не мешает себя представить банком из 32 маленьких подбанков под одним управлением и общим лейблом (у ОПСОСов так и происходит).
И поставить для каждого "подбанка" отдельный, независимый процессинг - тем самым минимизировать масштаб и последствия глобальных
отказов, удешевить затраты на оборудование и ПО (серверы по цене растут совсем нелинейно от мощности).

Сейчас пока известно лишь то, что наши банки так не делают - мелочевке это не актуально, а у крупных еще понимание не
наступило, хотя недавние эпические отказы вроде бы должны были надоумить.
Если про Сбер, то допустим OracleRAC их бы не спас от переполнения СХД под редо.
Или вы предлагаете руками шардировать и у ОПСОСов так же делают?
...
Рейтинг: 0 / 0
Плюсы против голого Си, холивар #9
    #37953100
[quot донкихот]Проясним ситуацпропущено...


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

Все эти 3БНФ - это хорошо для студентов, теоретиков и баз данных вида АРМ-Кадры размером с 100MB.
Но при количестве фактов более 10млн в день обычно науступает просветвление.
В случае банков жертвуют скоростью ради надежности, нельзя чтобы все писали что попало, надо проверять.


Причем тут скорость, причем тут надежность?

Вот стоит четыре банкомата. Какая разница, сколько за ними банков - четыре разных или один, которые обслуживает их все четыре?

Как быстрее будет? Четыре разных, или один большой? Подумай хорошо (на предмет конкуренции за некий разделяемый ресурс, блокировок и прочего).

донкихотЯ так понимаю "высоконагруженными базами данных" для OLTP задач и у вас обычно все необходимые данные кэшированы в ОЗУ?

Это уже прояснялось. Если workset активно обновляется - да, он хранится в ОЗУ. Если данные перетекли в историческую плоскость, и интересны только аналитикам - там все компрессируется (поколоночно), специальными джобами, за счет переноса
в другие БД, где в ОЗУ практически ничего не хранится, т.к. шанс того, что обрабатываемые 10 терабайт уместятся в достижимые на сегодняшний день объемы ОЗУ - ничтожно мал.
...
Рейтинг: 0 / 0
Плюсы против голого Си, холивар #9
    #37953168
донкихотЕсли про Сбер, то допустим OracleRAC их бы не спас от переполнения СХД под редо.
Ты походу попутал RAC - share everything, и sharding - share nothing.
Сходил бы подучил основы, а потом бы вещал истины, а?

донкихотИли вы предлагаете руками шардировать и у ОПСОСов так же делают?
Да, именно руками и делают. Абоненты Москвы вручную привязаны к одним серверам и базам, а какого Питера - к другим, и обе группы
друг про друга ничего не знают, физически и логически они вообще друг для друга - абоненты разных операторов. Не знал?
...
Рейтинг: 0 / 0
Плюсы против голого Си, холивар #9
    #37953261
донкихот
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Проясним ситуацдонкихотИли вы предлагаете руками шардировать и у ОПСОСов так же делают?
Да, именно руками и делают. Абоненты Москвы вручную привязаны к одним серверам и базам, а какого Питера - к другим, и обе группы
друг про друга ничего не знают, физически и логически они вообще друг для друга - абоненты разных операторов. Не знал?
И почему же в банках так не делают, как считаешь?
...
Рейтинг: 0 / 0
Плюсы против голого Си, холивар #9
    #37953283
Фотография iv_an_ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
донкихотТянуть данные с разных серверов для мелких транзакций это большие относительные задержки.Ну и что? на том конце сидит медленное устройство ввода-вывода под названием "человек". Собирайте мелкие транзакции в векторы по 10000--100000, но не формируйте вектор дольше 1/10 секунды, если у вас в 1/10 секунды проходит меньше 10000 транзакций. Тогда ценой лишних 1/10 секунды задержки вы можете уменьшить число обменов в кластере в эти самые 10000 раз. Или не собирайте их в векторы, собирайте просто в пакеты --- тоже будет совсем неплохо.
донкихотПо какому ключу нарезать справочники?По уникальному целочисленному, как подсказывает К.О.
донкихотденормализацию, чтобы каждый писал в "факты" что захочется, без обращения к справочнику для хотя бы минимальной проверки сразу Я не понимаю, чем денормализация может помешать валидации ввода, особенно если все данные или валидны или нет строго на момент ввода, и задним числом ничего не правится.
...
Рейтинг: 0 / 0
Плюсы против голого Си, холивар #9
    #37953292
донкихотПроясним ситуацпропущено...

Да, именно руками и делают. Абоненты Москвы вручную привязаны к одним серверам и базам, а какого Питера - к другим, и обе группы
друг про друга ничего не знают, физически и логически они вообще друг для друга - абоненты разных операторов. Не знал?
И почему же в банках так не делают, как считаешь?


Делают, просто в РФ крупных банков только один, остальным это просто не актуально - не те объемы данных.
Даже самый крупный пока справляется вертикальным масштабированием - тупо покупает более мощное железо.

У ОПСОСов проблемы с базами данных начались намного раньше и глобальнее - человек в среднем за сутки
делает порой по 10-20 звонков, но лишь один раз в день (и то не каждый) пользуется пластиковой картой.

Т.е. 100 млн транзакций какой Sun M8000 или p795 за сутки пережует легко (реально там сильно меньше, в районе 50-60 млн операций в сутки), а вот 2 млрд - уже врядли.

Ваш КО
...
Рейтинг: 0 / 0
Плюсы против голого Си, холивар #9
    #37953299
донкихот
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Проясним ситуацДелают, просто в РФ крупных банков только один, остальным это просто не актуально - не те объемы данных.
Например в каком иностранном банке так?
...
Рейтинг: 0 / 0
Плюсы против голого Си, холивар #9
    #37953311
Фотография iv_an_ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Проясним ситуацУ ОПСОСов проблемы с базами данных начались намного раньше и глобальнее - человек в среднем за сутки
делает порой по 10-20 звонков, но лишь один раз в день (и то не каждый) пользуется пластиковой картой.Там и по числу клиентов бывают различия. Скажем, у China Mobile 300000000 "живых" абонентов, у сбера столько бабушек никак не наберётся.
...
Рейтинг: 0 / 0
Плюсы против голого Си, холивар #9
    #37953315
донкихотПроясним ситуацДелают, просто в РФ крупных банков только один, остальным это просто не актуально - не те объемы данных.
Например в каком иностранном банке так?

В любом глобальном (международном).
...
Рейтинг: 0 / 0
Плюсы против голого Си, холивар #9
    #37953329
донкихот
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
iv_an_ruдонкихотТянуть данные с разных серверов для мелких транзакций это большие относительные задержки.Ну и что? на том конце сидит медленное устройство ввода-вывода под названием "человек". Собирайте мелкие транзакции в векторы по 10000--100000, но не формируйте вектор дольше 1/10 секунды, если у вас в 1/10 секунды проходит меньше 10000 транзакций. Тогда ценой лишних 1/10 секунды задержки вы можете уменьшить число обменов в кластере в эти самые 10000 раз. Или не собирайте их в векторы, собирайте просто в пакеты --- тоже будет совсем неплохо.
100мс это большие задержки. Маленькие это 10мкс.

iv_an_ruдонкихотденормализацию, чтобы каждый писал в "факты" что захочется, без обращения к справочнику для хотя бы минимальной проверки сразу Я не понимаю, чем денормализация может помешать валидации ввода, особенно если все данные или валидны или нет строго на момент ввода, и задним числом ничего не правится.
А на основании чего делать валидацию, не на основании ли данных из справочника филиалов?
...
Рейтинг: 0 / 0
25 сообщений из 228, страница 6 из 10
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Плюсы против голого Си, холивар #9
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]