MIN/MAXПроясним ситуацпропущено...

Ты опять решил рассказать, что понятия не имеешь про денормализацию данных? Ну так поясним еще раз. Все группировки делаются заранее, считаются и сохряняются в базу. Данные хранятся в уже сортированном виде, готовом для отдачи клиенту без какой-либо обработки.
Имеете ввиду MatView с QueryRwerite?
А как мне апдейтнуть такую MatView содержащую агрегаты MIN/MAX , когда в исходных таблицах возможнен (UPDATE ... STATUS = 0), их размер несколько ТБ, если по бизнес требованиям отставание данных в ней (агрегированной MatView) должно не превышать 2 минут для любого запроса?
Надеюсь понятно, что частичное обновление именно таких MatView невозможно и не реализовано ни в одной СУБД.
Это реальная задача из банковской сферы.
То, что я расписывал - это задача из OLTP сферы - обслуживание тысяч клиентов в режиме приближенном к real-time.

А ты пришел ко мне с противным DWH/DSS - мы не решаем это и не собираемся решать - для этих задач базы данных дампятся из шард, с предварительной агрегацией, а потом уже заливаются в специализированные хранилища данных, вроде netezza, и там уже аналитики резвятся как хотят, через SQL и не только. В той области масса годных готовых решений (ну, наверное, я не в курсе всех тенденций).

MIN/MAXПроясним ситуацПлюс вопрос компрессии - еще тот вопрос. Скомпрессировать блок на диске - это ок, много ума не надо, через btrfs или zfs. А если хранить его развернутым уже в памяти, то это уже ой.

А так как сервер у вас SQL (Oracle?), то об эффективности компрессии OLTP данных можно можно только поулыбаться.
Кстати, интересно, а в вашей системе в ОЗУ данные хранятся в сжатом виде и каким алгоритмом жмете?

Если реально - то были попытки привинтить snappy и zlib, но синтетические тесты показали противоречивые результаты.
Типовой паттерн - это рандомизированное чтение, т.е. отдельный пользовательский запрос берет всего один блок данных, и с точки зрения стоимости чтения с диска - вообще никакой разницы нет, только CPU напрасно расходуется.

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

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

Одним словом - сейчас осталась только компрессия на самых старых данных (time lag больше месяца), они сжимаются через btrfs lzo просто для того, чтоб места занимали поменьше, так их вообще редко кто читает по-блочно и просад производительности не критичен.

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

Но вот на задачах подготовки данных для DSS (предварительная агрегация и фильтрация) компрессия дает как раз строго обратные результаты - там преобладает линейное,
последовательное чтение (перебираем таблицы фактов при построении агрегатов), и тот факт, что данных приходится читать с диска в 9-10 раз меньше - дает огроменный результат - т.е. ускорение до 5-6 раз минимум. Там пока решено оставить btrfs, плюс память сразу высвобождается после чтения, потому что шанс того, что перемолоченные пару терабайт данных хоть как-то прокешируются в тех 32 гигабайтах ОЗУ на ноде и будут кем-то востребованы - ничтожно мал.

без иронии и без намековПроясним ситуацКогда я несколько раз говорил про madvise - никто не понял тонкой иронии в виде очень прямого намека. Забавно....

Это наверное так трудно - сдалать man madvise, да?
Скажу без иронии и без намеков, сколько не давай советов и подсказок глупому алгоритму кэширования в mmap он будет далек от кэширования самим Oracle, причем на порядок.
Если сравнивать с кэшированием в MySQL, то да, наверное вы правы.

Ты думаешь в Oracle алгоритм кеширования супер-мега интеллектуален?

Впрочем, не будем разбивать мечты и надежды....

iv_an_ruПроясним ситуацКогда я несколько раз говорил про madvise - никто не понял тонкой иронии в виде очень прямого намека. Забавно....Очень хотелось бы увидеть удовлетворительную демку с mmap без больших страниц на 256+ гигах ОЗУ и хотя бы терабайте данных, лежащих на 6 обычных HDD. Самый обычный самый дешёвый комодный ящик, без заморочек с RAID и SAN, то есть на железе, для которого ядро отполировано лучше всего. Хоть с мадвайзами хоть без.

Комодный ящик сейчас - это 32-64 гигабайт ОЗУ, выше - уже нерентабельно, намного дешевле и эффективнее купить четыре ящика по 64, чем один ящик, набитый до 256 гигов ОЗУ.

А за демками... пишите письма, вам обязательно ответят.

iv_an_ruбез иронии и без намековсколько не давай советов и подсказок глупому алгоритму кэширования в mmap он будет далек от кэширования самим Oracle, причем на порядок.Да там даже не в алгоритме проблема, а в железе. Когда я сам выделяю дисковые буферы, я уж точно позабочусь, чтобы TLB были huge. Если я попытаюсь рулить терабайтом адресов в виде 4-килобайтных страничек (т.е. аж по _два_ TLB энтри на каждую 8-килобайтную страничку), то сами посчитайте размер таблички трансляции. Ядро тупо повесится её обновлять.
А разработчики ядра-то и не знают!


iv_an_ruи цена одного промаха мимо аппаратного TLB кэша легко достигает 80(!) циклов.

КАК СТРАШНО СТАЛО ЖИТЬ! 80 циклов супротив цены одного seek на HDD

Стивен Спилберг и Стивен Кинг продакшин. Новые, душераздирающие истории на в новой книге "Однажды, на улице 81-го цикла!"

iv_an_ruПроясним ситуацпропущено...
КАК СТРАШНО СТАЛО ЖИТЬ! 80 циклов супротив цены одного seek на HDDНе-е, вы не врубились. Эти 80 циклов будут вылезать просто на доступе к странице, которая _уже_ лежит в памяти. Причём два раза на дисковый буфер --- в его начале и в его середине. Особенно "приятно", если с этой страницы и прочитать-то надо было всего пяток слов.

Только при первом чтении. Количество активных процессов в момент времени - не более 16 (по одному-два на кору), для них вот того DTLB with 64 entries for 4 KiB pages - более чем достаточно - типовой сценарий - мы долбим страницу данных, страницу результата и еще стека и кода.

Так что мимо, пишите еще ужастикофф.

Проясним ситуацТак что мимо, пишите еще ужастикофф.

http://www.realworldtech.com/nehalem/8/

Тем более, что DTLB для каждой коры - свой, плюс еще есть L2 TLB...


Колокола, звенят колокола, почём у нас колокола? По 80 циклов, да?


авторAs a result, each Nehalem core features a combined TLB of 576 entries that sum up to 2304 total for the entire processor, enough to cover 9.2 MB – way in excess of the actual L3 cache size.

iv_an_ruПроясним ситуацКомодный ящик сейчас - это 32-64 гигабайт ОЗУ, выше - уже нерентабельно, намного дешевле и эффективнее купить четыре ящика по 64, чем один ящик, набитый до 256 гигов ОЗУ.Кому как.
Да хоть кому. Расчет прост - стоимость железяки/сколько клиентов сможет обслужить железяка. Дальше тупо берем чуть дальше, чем где полный минимум.

Мы вот вообще ждем - когда же уже ARM появится, 64-х битный. Мощностей Xeon-ов, при переписанном движке БД и вебсервере - вообще не нужно, они на 99% в idle, только лектричество даром кушают.


iv_an_ru Особенно если к четырём ящикам вместо одного понадобится вчетверо больше портов хотя бы мелланоксовского инфинибанда.
Не понадобится, и это уже даже близко не commodity.

iv_an_ruOTOH у нас "некомодный" ящик --- 6 "горизонтальных" лезвий на морде и 4 коммуникационных вертикальных лезвия на попе, к примеру. Но их только клиенты себе покупают, мы для разработки пока комодами обходимся. В Нске одна такая лезвийная гробина стоит от миллиона рублей, даже если экономить и брать его в шасси местного производства --- нафиг оно надо, такие деньги тратить без крайней нужды.

И что с того? Какая разница, на чем вы там у себя в росейской глубинке откатушки делаете?

Откровенно не интересна эта тема, вот честно. У тебя наболело - обратись к специалистам, там посочувствуют.

iv_an_ruПроясним ситуацпропущено...
... if the access is dense enough.

"Плохие" паттерны доступа + 4-килобайтные страницы = Большая Попа. Иначе зачем бы вообще придумывали большие страницы.
А с другой стороны, массовое тягание больших страниц туда-сюда = Вообще Мега-Попа, потому что в 64 мега внутреннего кэша диска садятся всего 16 таких 4 меговых страничек, ну и вообще мало кайфа таскать такие объёмы впустую.

Не забываем, что основной веб паттерн (RESTful)

а) получили из соката запрос в 110 байт
б) сходили в базу занных с хеш ключом в 32 байт (попадание три-четыре старницы), получили в итоге 200-300 байт данных
в) обработали 200-300 байт данных, сформировали 800-1200 байт ответа, отдали ядру на отправку в сокет.

Тут и Celeron отлично справится, с 256к L2, при 16 шардов-процессов


В общем опять мимо, опять... да что-же так!

А больше страницы нужны для вона обработки видео какого, фоточек там, подобного, как я понимаю

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

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


Проясним ситуацСжатие в ZFS конечно далеко не дотягивает по скорости до snappy, а вот последний вполне может подойти. Естественно все это справедливо если имеется большой перекос в сторону избытка CPU и недостатка СХД IO.

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

Знаю точно - мы боролись за высокий response time для клиента. Соотвественно была задача - сделать sync для логированной записи (это сильно меньше, чем один килобайт). И скорее всего snappy там только вносил тормоза, тогда как простейший RAID1 с батарейкой давал практически моментальный ответ на sync, упаковывая уже несколько log записей в один физически 4-х килобайтный (а то и 128 килобайтный) блок.