Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6   вперед  Ctrl      все
 Re: Поговорим о масштабировании  [new]
iv_an_ru
Member

Откуда: Новосибирск
Сообщений: 20368
промасштабировался дальше
iv_an_ru
Процы заняты полезным делом. Но если ставить эту конкретную задачу на один ящик с терабайтом ОЗУхи, то считайте сами --- 50 гигафактов в сжатых колонках, примерно по 6 байт на факт, дадут 300 гигабайт.

А запросы тратят CPU больше всего на индексный поиск, агрегацию, скалярные функции или на внутренние нужды?
Это уж от запросов зависит, ну и хранимки сами по себе тоже жрут хорошо, тем более что есть ведь и такие "длинные" функции, как применение XSLT или обогащение HTML-ного документа дополнительными сылками.
промасштабировался дальше
iv_an_ru
Тем более, что они хотят на нём прогнать BSBM / BIBM / TPC-H / RDF-H, и нам совсем не улыбается увидеть публичные отчёты с издевательски большими $/QMpH и $/QphH.

Если они это IBM, то ничего удивительного :)
Нет, не IBM, хотя тоже три буквы. Как отчёты опубликуют, так можно будет и сказать, кто.
15 сен 11, 19:18    [11283618]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
модель представления данных
Guest
iv_an_ru, кстати у вас виртуоза это СУБД с вертикальным хранением RDF, блокировочник и с кластером архитектуры MPP(shared nothing)?
28 сен 11, 01:27    [11345510]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
iv_an_ru
Member

Откуда: Новосибирск
Сообщений: 20368
модель представления данных
iv_an_ru, кстати у вас виртуоза это СУБД с вертикальным хранением RDF, блокировочник и с кластером архитектуры MPP(shared nothing)?
Да, это "жёсткий" блокировочник и shared nothing cluster, версии до седьмой умеют только горизонтально хранить, седьмая (пока ещё не общедоступная) умеет и вертикально хранить (причём не только RDF :). Ну а главный источник доходов --- виртуальная схема, в которой для разработчика приложений нет разницы между таблицами, хранящимися на самой виртуозе и таблицами, лежащими на присоединённых серверах других вендоров.
28 сен 11, 09:38    [11345916]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
модель представления данных
Guest
iv_an_ru
модель представления данных
iv_an_ru, кстати у вас виртуоза это СУБД с вертикальным хранением RDF, блокировочник и с кластером архитектуры MPP(shared nothing)?
Да, это "жёсткий" блокировочник и shared nothing cluster, версии до седьмой умеют только горизонтально хранить, седьмая (пока ещё не общедоступная) умеет и вертикально хранить (причём не только RDF :). Ну а главный источник доходов --- виртуальная схема, в которой для разработчика приложений нет разницы между таблицами, хранящимися на самой виртуозе и таблицами, лежащими на присоединённых серверах других вендоров.

А что значит "жесткий" блокировочник? :)
Да, такая виртуальная схема снимает вопрос о необходимости миграции на другую СУБД. Можно использовать обе :)

Кстати у вас каждая нода владеет своим куском данных и не может передавать их на владение другой ноде как в Oracle RAC, поэтому необходимость в синхронизации блокировок есть только между дублирующими серверами?
28 сен 11, 12:21    [11347149]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
iv_an_ru
Member

Откуда: Новосибирск
Сообщений: 20368
модель представления данных
А что значит "жесткий" блокировочник? :)
Он даже не пытается как-то переупорядочить транзакции, чтобы уменьшить число роллбэков или сделать ещё что умное. Как результат, среди транзакций полная "дедовщина" --- если случается дедлок, то всегда откатывается та транзакция, которая к этому моменту захватила меньше данных, без каких-либо "смягчающих обстоятельств". Для защиты от слишком блокирующих запросов есть "anytime query" --- можно указать, что запрос не должен нормально выполняться дольше такого-то времени, по достижении таймера у запроса возникает иллюзия, что все таблицы внезапно "опустели", и он волей-неволей возвращает частичный результат. Зато при необходимости транзакции могут длиться часами, хорошо бегают распределённые транзакции и checkpoint проходит совершенно незаметно для всех транзакций.
28 сен 11, 12:44    [11347363]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
iv_an_ru
Member

Откуда: Новосибирск
Сообщений: 20368
модель представления данных
Кстати у вас каждая нода владеет своим куском данных и не может передавать их на владение другой ноде как в Oracle RAC, поэтому необходимость в синхронизации блокировок есть только между дублирующими серверами?
Совершенно верно. При этом есть возможность эскалации блокировок (автоматической замены многих строковых одной страничной) + возможность создавать частичные индексы + для маньяков возможность на уровне приложения писать в разные индексы таблицы отдельными операторами. Всё это снижает затраты на синхронизацию.
28 сен 11, 12:49    [11347425]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
модель представления данных
Guest
iv_an_ru
возможность создавать частичные индексы + для маньяков возможность на уровне приложения писать в разные индексы таблицы отдельными операторами. Всё это снижает затраты на синхронизацию.

Частичные индексы - это partial index по диапазонам так понимаю. А что значит писать в разные индексы?
Упрощение взаимодействия по идее должно сильно повысить масштабируемость.

Кстати, примерно во сколько раз получается выигрыш в производительности от применения вертикального хранения, в 2, 5, 10, 100?
28 сен 11, 13:18    [11347697]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
iv_an_ru
Member

Откуда: Новосибирск
Сообщений: 20368
модель представления данных
iv_an_ru
возможность создавать частичные индексы + для маньяков возможность на уровне приложения писать в разные индексы таблицы отдельными операторами. Всё это снижает затраты на синхронизацию.

Частичные индексы - это partial index по диапазонам так понимаю.
Это когда в индексе есть только некоторые из колонок primary key, напр.

create table DB.DBA.RDF_QUAD (
  G IRI_ID_8,
  S IRI_ID_8,
  P IRI_ID_8,
  O any,
  primary key (P, S, O, G)
  )
alter index RDF_QUAD on DB.DBA.RDF_QUAD partition (S int (0hexffff00))

create distinct no primary key ref bitmap index RDF_QUAD_SP on RDF_QUAD (S, P) partition (S int (0hexffff00))
create bitmap index RDF_QUAD_POGS on RDF_QUAD (P, O, G, S) partition (O varchar (-1, 0hexffff))
create distinct no primary key ref bitmap index RDF_QUAD_GS on RDF_QUAD (G, S) partition (S int (0hexffff00))
create distinct no primary key ref index RDF_QUAD_OP on RDF_QUAD (O, P) partition (O varchar (-1, 0hexffff))
;
В таком варианте если будет поиск по таблице с условием S=const, то сначала в RDF_QUAD_SP будут найдены все P, которые встречаются в RDF_QUAD вместе с данным значением S, и потом уже будут поиски в P,S,O,G по двум первым заданным колонкам.
А если только G известно, то ищем G в RDF_QUAD_GS, потом S в RDF_QUAD_SP, потом P и S в P,S,O,G c проверкой G. При этом неполные индексы настолько малы, что ложатся в память, а полных индексов всего два вместо четырёх.

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

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


Упрощение взаимодействия по идее должно сильно повысить масштабируемость.

Кстати, примерно во сколько раз получается выигрыш в производительности от применения вертикального хранения, в 2, 5, 10, 100?[/quot]
28 сен 11, 13:44    [11347929]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
iv_an_ru
Member

Откуда: Новосибирск
Сообщений: 20368
модель представления данных
Упрощение взаимодействия по идее должно сильно повысить масштабируемость.

Ещё б совпадали "упрощение для машины" и "упрощение для разработчика" :(
модель представления данных
Кстати, примерно во сколько раз получается выигрыш в производительности от применения вертикального хранения, в 2, 5, 10, 100?
Выигрыш там в памяти. На если после этого активное подмножество начинает целиком умещаться в память, а диск только обновления пишет, то и по скорости выигрыш образуется.

Я вот тут подробней рассказывал, правда не совсем СУБДшникам: Облако и куб: RDF в аналитической базе данных, и тут в конце тоже ссылки на русскоязычные конспекты по RDF/SPARQL .
28 сен 11, 13:54    [11348019]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
модель представления данных
Guest
iv_an_ru
модель представления данных
Упрощение взаимодействия по идее должно сильно повысить масштабируемость.

Ещё б совпадали "упрощение для машины" и "упрощение для разработчика" :(

Имеется ввиду разработчик который разрабатывает СУБД или разработчик который разрабатывает БД?
iv_an_ru
модель представления данных
Кстати, примерно во сколько раз получается выигрыш в производительности от применения вертикального хранения, в 2, 5, 10, 100?
Выигрыш там в памяти. На если после этого активное подмножество начинает целиком умещаться в память, а диск только обновления пишет, то и по скорости выигрыш образуется.

Я вот тут подробней рассказывал, правда не совсем СУБДшникам: Облако и куб: RDF в аналитической базе данных, и тут в конце тоже ссылки на русскоязычные конспекты по RDF/SPARQL .

Интересно, что-то вы там серьёзное делаете :)
На сколько я понял для RDF было отставание в 3 раза от реляционной модели, а после применения работ Абади стало примерно равно?
И "производительность по RDF-H наконец-то оказалась сравнима с производительностью TPC-H" уже с учетом того, что в реляционной модели также применили вертикальное хранение или в реляционной оно не дает заметного выигрыша?

Раньше реляционные сжимались лучше, а сейчас при вертикальном хранении данные сжимаете и насколько хорошо они сжимаются относительно реляционной модели?
Кстати, а почему вы говорите "К тому же эта мера ускоряет чтение с жёсткого диска, но не снижает требований к размеру ОЗУ." В чем проблема хранить в ОЗУ сжатые данные?
2 окт 11, 20:25    [11370403]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
iv_an_ru
Member

Откуда: Новосибирск
Сообщений: 20368
модель представления данных
На сколько я понял для RDF было отставание в 3 раза от реляционной модели, а после применения работ Абади стало примерно равно?
...
Раньше реляционные сжимались лучше, а сейчас при вертикальном хранении данные сжимаете и насколько хорошо они сжимаются относительно реляционной модели?

При старом "горизонтальном" хранении TPC-H масштаба 1G ложился в 140000 страниц, RDF-H того же масштаба жрал 630000 страниц.
При новом "вертикальном" хранении тот же TPC-H усох до 90000 страниц, а RDF-H --- до 250000 страниц.

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

RDF никогда не догонит "классику" по масштабируемости и по скорости. Но он не догонит на тех задачах, на которых классические методы _применимы_. Когда в базе знаний что-то сделать _можно_, а в базе данных --- _нереально_, уже как-то не важно, во сколько раз база данных была бы быстрее, будь это реально. В итоге будущее, безусловно, за гибридами, чтобы разработчики приложений могли для каждого куска использовать наиболее подходящую комбинацию инструментов.
Ну а пока сообщество старательно делится на СУБД-шников и СУБЗ-сников. Это такой же идиотизм, как если бы строители делились на сторонников использования одних только кирпичей и сторонников использования одного только цементного раствора --- и это после изобретения нормальной кладки :)

RDF-H --- это как раз тест, показывающий самый плохой случай для RDF, если сравнивать с классикой. Методы разгона TPC-D (и теперь TPC-H) полировались десятилетиями, и это ровно то, для чего SQL и создавался в первую очередь. В то же время тупой экспорт этих данных в RDF-H и "лобовой" перевод запросов из SQL в SPARQL не демонстрирует никаких преимуществ базы знаний, они разрабатывались для другого.

модель представления данных
Кстати, а почему вы говорите "К тому же эта мера ускоряет чтение с жёсткого диска, но не снижает требований к размеру ОЗУ." В чем проблема хранить в ОЗУ сжатые данные?
Чтобы и в памяти хранить сжатые данные, надо многократно разжимать их большими кусками. Это не только расходует время само по себе, но и забивает кэш процессора, что чревато падением производительности остального кода буквально на порядок.
2 окт 11, 22:47    [11370987]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
модель представления данных
Guest
Т.е. RDF от вертикального хранения выиграл больше :)

iv_an_ru
модель представления данных
Кстати, а почему вы говорите "К тому же эта мера ускоряет чтение с жёсткого диска, но не снижает требований к размеру ОЗУ." В чем проблема хранить в ОЗУ сжатые данные?
Чтобы и в памяти хранить сжатые данные, надо многократно разжимать их большими кусками. Это не только расходует время само по себе, но и забивает кэш процессора, что чревато падением производительности остального кода буквально на порядок.

В принципе да. Здесь вопрос в том насколько действительно большой разрыв в производительности систем хранения и исполнения. И насколько неоднородно идет обращение к данным.
Если к одним данным идет в 100 раз больше запросов чем к другим, то да.
Если достаточно однородно, то в любом случае расжать из ОЗУ будет быстрее чем поднять с диска.
2 окт 11, 23:03    [11371071]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
iv_an_ru
Member

Откуда: Новосибирск
Сообщений: 20368
модель представления данных
В принципе да. Здесь вопрос в том насколько действительно большой разрыв в производительности систем хранения и исполнения. И насколько неоднородно идет обращение к данным.
Если к одним данным идет в 100 раз больше запросов чем к другим, то да.
Если достаточно однородно, то в любом случае расжать из ОЗУ будет быстрее чем поднять с диска.

Когда-то давно, когда для "крутых персоналок" стандартом были 2 мегабайта ОЗУ, продавал я одну расчётную софтинку, которая просила возмутительные 4 мегабайта ОЗУ. Потом вылез у меня конкурент, который стал как раз сжимать данные, и для многих задач стал укладываться в обычные 2 мегабайта. Обычная задачка у меня обсчитывалась за обеденный перерыв, у него --- за ночь.
Закопал я "вражину" простым демпингом. Если клиент ворчал, что вот люди и на двух считают, и его задача действительно со сжатием влезала в 2 мега, то я обещал ему при покупке моей программулины подарок --- недостающие два мега.

...тогда я пообещал себе, что никогда не буду пытаться сжимать память...
2 окт 11, 23:27    [11371163]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
модель представления данных
Guest
iv_an_ru, я согласен, хорошая метафоричная история.
Но допустим доступ к дисковому массиву 600 МБс, доступ к памяти четырехканальной 40 000 МБс, итого примерно 100 раз. Допустим всего ОЗУ 64 ГБ, допустим половина под дисковый кэш (32 ГБ).
Что лучше, иметь доступ к 32 ГБ со скоростью 40 000 МБс (в 100 раз), или к 64 ГБ со скоростью 4 000 МБс (в 10 раз)?
Причем мы говорим именно про дисковый кэш, а не всю память сжимать-разжимать ;)
И причем 600 МБс это последовательные IO к диску, а случайные 60 МБс, т.е. разница будет нет 100 и 10, а 1000 и 100 раз ;)
2 окт 11, 23:45    [11371208]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
iv_an_ru
Member

Откуда: Новосибирск
Сообщений: 20368
модель представления данных
iv_an_ru, я согласен, хорошая метафоричная история.
Но допустим доступ к дисковому массиву 600 МБс, доступ к памяти четырехканальной 40 000 МБс, итого примерно 100 раз. Допустим всего ОЗУ 64 ГБ, допустим половина под дисковый кэш (32 ГБ).
Что лучше, иметь доступ к 32 ГБ со скоростью 40 000 МБс (в 100 раз), или к 64 ГБ со скоростью 4 000 МБс (в 10 раз)?
Причем мы говорим именно про дисковый кэш, а не всю память сжимать-разжимать ;)
И причем 600 МБс это последовательные IO к диску, а случайные 60 МБс, т.е. разница будет нет 100 и 10, а 1000 и 100 раз ;)

Рассмотрим грустный пример. Нужно вам сделать index lookup, взять целое поле по целому ключу, 160 байт на одну строку таблицы, 50 строк в странице.

Несжатая память: вы двоичным поиском дёргаете 8 слов плюс девятое слово-значение, и перед тем "нулевое" слово --- версия индекса, с которой создавалась страница и всякие флаги. Трафик 10 64-битных строк кэша проца, readonly.

Сжатая память: вы разжимаете 8 килобайт (т.е. 1000 строк кэша проца) в 16 килобайт (ещё 2000 строк, причём записи, за что NUMA подтормозит дополнительно). Итого только непосредсвенные затраты на трафик в 400 раз больше --- из 4000 перелопаченных строк реально понадобятся только 10. Такой КПД приводит к тому, что условные 40 000 МБс принесли полезных данных всего-то 100МБс, что удручающе похоже на приличный массив дисков.
А ещё мы нагадили в кэш проца, ну и вообще проц заняли "чем попало", потеряв в скорости.

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

Вывод. Если денег на ОЗУ жестоко не хватает, то нужно ещё немножко урезать ОЗУ, а на сэкономленное купить SSD.
3 окт 11, 00:23    [11371334]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
модель представления данных
Guest
iv_an_ru
в 16 килобайт (ещё 2000 строк, причём записи, за что NUMA подтормозит дополнительно).

А тут NUMA подтормозит в предположении, что проц может писать не в свою память или из-за выяснений куда писать?

iv_an_ru
Итого только непосредсвенные затраты на трафик в 400 раз больше --- из 4000 перелопаченных строк реально понадобятся только 10. Такой КПД приводит к тому, что условные 40 000 МБс принесли полезных данных всего-то 100МБс, что удручающе похоже на приличный массив дисков.

В принципе да, только если уж говорим про кэш проца, то это уже не 40 000 МБс и 100 МБс, а на пару порядков больше :)
Но в любом случае конечно index lookup здесь не выиграет.
А вот index scan вполне бы мог ;)
3 окт 11, 10:52    [11372191]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
отличие RDF от EAV
Guest
iv_an_ru ,
А в чем отличие RDF от EAV или это синонимы?
14 окт 11, 20:42    [11444066]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
iv_an_ru
Member

Откуда: Новосибирск
Сообщений: 20368
модель представления данных
iv_an_ru
в 16 килобайт (ещё 2000 строк, причём записи, за что NUMA подтормозит дополнительно).

А тут NUMA подтормозит в предположении, что проц может писать не в свою память или из-за выяснений куда писать?
Из-за распространения "разметки загрязнений", чтобы другие процессоры пометили строку в кэше как устаревшую, если она содержит данные из свежезаписанного куска памяти.
модель представления данных
iv_an_ru
Итого только непосредсвенные затраты на трафик в 400 раз больше --- из 4000 перелопаченных строк реально понадобятся только 10. Такой КПД приводит к тому, что условные 40 000 МБс принесли полезных данных всего-то 100МБс, что удручающе похоже на приличный массив дисков.

В принципе да, только если уж говорим про кэш проца, то это уже не 40 000 МБс и 100 МБс, а на пару порядков больше :)
Но в любом случае конечно index lookup здесь не выиграет.
А вот index scan вполне бы мог ;)
Мы говорим про чтение в кэш проца из памяти, а не регистров из кэша. А index scan на большом масштабе... Если что-то не работает _ваапще_, то уже не важно, с какой именно скоростью оно не работает :) Вот на некоторых графических задачах действительно "index lookup" по "плиткам" изображения, там да, успешно сжимают именно память. Классический пример --- RIP на типографских фотовыводителях, особенно постскрипта.
14 окт 11, 21:29    [11444235]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
iv_an_ru
Member

Откуда: Новосибирск
Сообщений: 20368
отличие RDF от EAV
iv_an_ru ,
А в чем отличие RDF от EAV или это синонимы?
RDF --- это стандартизованный (потому переносимый) вариант EAV-представления. Я на одном семинаре рисовал разные варианты представления классического "мира кубиков". Из всех вариантов просто победил самый ограниченный, зато дешёвый :)
14 окт 11, 21:38    [11444287]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
модель представления данных
Guest
iv_an_ru
Мы говорим про чтение в кэш проца из памяти, а не регистров из кэша.

Да :)
С index lookup разобрались. Оверхеды на порядки больше чем выигрыш.

iv_an_ru
А index scan на большом масштабе... Если что-то не работает _ваапще_, то уже не важно, с какой именно скоростью оно не работает :)

А вот это не совсем понял.
14 окт 11, 21:50    [11444342]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
iv_an_ru
Member

Откуда: Новосибирск
Сообщений: 20368
модель представления данных
iv_an_ru
А index scan на большом масштабе... Если что-то не работает _ваапще_, то уже не важно, с какой именно скоростью оно не работает :)

А вот это не совсем понял.
С ростом базы обычно падает доля предикатов, которые давали бы значения в некоторых коротких диапазонах. Или фильтрация даёт почти уникальные (в масштабе базы) значения, и они оказываются раскиданы очень далеко друг от друга, или фильтрация оставляет такое количество значений, что их за разумное время обработать невозможно вообще --- за время обхода базы либо данные устареют, либо ответ уже не будет нужен, либо осёл/дрессировщик/падишах помрёт. Немудрячий запрос "сумма стоимостей междугородных звонков за сегодня" прекрасно сработает на сырых данных офисной АТС, но невозможен для China Mobile.
14 окт 11, 22:26    [11444460]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
модель представления данных
Guest
iv_an_ru
модель представления данных
пропущено...

А вот это не совсем понял.
С ростом базы обычно падает доля предикатов, которые давали бы значения в некоторых коротких диапазонах. Или фильтрация даёт почти уникальные (в масштабе базы) значения, и они оказываются раскиданы очень далеко друг от друга, или фильтрация оставляет такое количество значений, что их за разумное время обработать невозможно вообще --- за время обхода базы либо данные устареют, либо ответ уже не будет нужен, либо осёл/дрессировщик/падишах помрёт. Немудрячий запрос "сумма стоимостей междугородных звонков за сегодня" прекрасно сработает на сырых данных офисной АТС, но невозможен для China Mobile.

Т.е. для большой БД здесь два варианта:
1. Или фильтрация даёт почти уникальные (в масштабе базы) значения, и они оказываются раскиданы очень далеко друг от друга
2. или фильтрация оставляет такое количество значений, что их за разумное время обработать невозможно вообще --- за время обхода базы либо данные устареют...


1. Здесь в соответствии с кардинальностью будет выбран:
- index lookup, тогда как мы выяснили сжатие только добавит оверхед и сьест CPU
- index scan, тогда без сжатия пойдет загрузка в базу больших объемов данных и сжатие поможет

2. Здесь естественно идет index scan. На таких объемах данные секционируются по дням или чаще. Дневная секция составит к примеру 10^9 китайцев * 20 звонков за день в среднем = 20 * 10^9. Для сферического DWH в вакууме будет:
объем строки: 8 байт списанные деньги + 8 байт номер исходящего абонента + 8 байт входящего + 8 байт время разговора + хедер строки допустим как в PG 24 байта = 56 байт
объем дневной секции: 56 * 20 * 10^9 = 1.1 ТБ.

На RAID из 24 дисков со скоростью около 1 ГБ/сек эти данные загрузятся за 18 минут = (1100ГБ /1 ГБсек) / 60 сек
Обработает такой поток данных 2 CPU х 6 Cores.

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

И здесь вопрос, что лучше для увеличения скорости в 2 раза.
- увеличить в 2 раза СХД и CPU(в 2 раза больше дисков и быстрее работает СХД, в 2 раза надо больше CPU)
- увеличить в 4 раза CPU(4 CPU разжимают данные + 4 CPU их обрабатывают)
(предполагаем что сжатие идет в 2 раза, но обычно оно в 3-10 раз)
14 окт 11, 23:14    [11444663]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
iv_an_ru
Member

Откуда: Новосибирск
Сообщений: 20368
(набрал длинный ответ, но случайно нажал Ctrl-A вместо Shift-A, и продолжил набор :(

В двух словах --- 18 минут не получится, потому что по двум номерам "междугородность" не установить --- нужны дополнительные данные для роаминга, редиректов и т.п. Поэтому категорию запросов надо предусмотреть заранее, и либо предусматривать 2.5-нормальную форму для схемы, либо вкладываться в быстрый произвольный доступ, либо и то и то.
14 окт 11, 23:39    [11444785]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
модель представления данных
Guest
iv_an_ru
(набрал длинный ответ, но случайно нажал Ctrl-A вместо Shift-A, и продолжил набор :(

В двух словах --- 18 минут не получится, потому что по двум номерам "междугородность" не установить --- нужны дополнительные данные для роаминга, редиректов и т.п. Поэтому категорию запросов надо предусмотреть заранее, и либо предусматривать 2.5-нормальную форму для схемы, либо вкладываться в быстрый произвольный доступ, либо и то и то.

(8 байт номер исходящего абонента + 8 байт входящего) имеется ввиду 64 битные идентификаторы на справочники номеров. Справочники по сравнению с таблицей фактов будут на порядки меньше. Сжимать справочники или нет, конечно вопрос.
В любом случае отличие максимум в разы, получается примерно такой порядок на достаточно обычном серверном оборудовании. Хоть в звезде, хоть в снежинке.
14 окт 11, 23:57    [11444868]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
мьюеткс vs IPC
Guest
iv_an_ru
softwarer
В общем-то можно, но вряд ли это оптимальный путь. А вот где, почему и начиная с какого предела "нормальная" база тормозит по сравнению с "восьмушками" - имхо стоит тщательно изучить.
Да нечего там было изучать. Очень большая база с RDF и много-много юзеров, каждый из которых ковыряется read-only в одних и тех же "очень активных" данных плюс каких-то неповторяющихся "непопулярных". Под Linux, а у него есть противная особенность: просто вход и выход из мьютекса не стоят почти ничего, а вот начало ожидания на мьютексе стоит примерно столько же, сколько целая выборка строки по ключу. В случае кластера проблемы с мьютексами уменьшились настолько, что экономия перевесила даже IPC. Поскольку для такого эффекта нужно, чтобы сервер "лёг на полку", не справляясь с нагрузкой, на практике такой сценарий просто не должен встречаться.

(Потом появились деньги, и вместо одного ящика поставили 8. Как раз вовремя, потому что база подросла до 2.5e10 фактов, ну и юзеров ещё больше стало.)

А это только в Linux такая особенность, что ожидание занятых ресурсов через мьютекс съедает больше чем межпроцессный обмен по IPC?
Или в Unix(AIX)/Solaris/Windows также?
7 ноя 11, 09:02    [11556182]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить