iv_an_ruПроясним ситуацОткрой для себя стандартные POSIX getcontext, setcontext...тогда уж просто pthreads и заюзать, вспоминая, что "The obsolescent functions getcontext(), makecontext(), and swapcontext() can be replaced using POSIX threads functions." :)
Да, конечно проще, заодно и смириться, что для 1000 keep-alive коннектов нам придется зарезервировать примерно 32 гигабайта памяти чисто под стек (одна сессия - один тред, 32 метра стека на тред).

Ура ура.


iv_an_ruМешает ровно один грустный факт --- вы этим все реплицированные данные нод размножили в 16 экземплярах. А кэш проца вы не размножили.
Какая-то откровенная ерунда. А что, при pthreads кеш процессоров размножается? Да неужели?

iv_an_ruНу и ещё куча мелочей, вроде возможности зарезервировать гигов пять на ноду под тяжёлые буферы, пока это 5*4=20 гигов на ящик, и невозможность --- если это 16*5*4 гигов на ящик.
Я сказал - mmap можно привязать к конкретной ноде, в чем проблема? Ты не знаешь что такое mmap и евойный map_policy?

iv_an_ruПроясним ситуацАх да, сервер баз данных тоже свой, из отряда доработанного dbmМолодец, возьми с полки пирожок. Но есть ньюанс --- за 30 с хвостиком последних лет аппетиты приложений слегка подросли, и в возможности *дэбээм не влезают никак. соответственно и инструментарий на серверной стороне слегка поменялся.

Расскажи это чувакам из redis и facebook (которые юзают mysql исключительно как key-value стораж), заодно и услышишь
от них авторитетное мнение о твоих .... ээээ.... экспертных познаниях об аппетитах приложений.

Детский сад, право.

Ты походу вообще выпал из струи прогресса и современных highload течений.

iv_an_ruМешает ровно один грустный факт --- вы этим все реплицированные данные нод размножили в 16 экземплярах. А кэш проца вы не размножили.

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

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

Что-то у тебя совсем плохо с основами.

iv_an_ruА при чём тут mmap? Вот надо мне на коротенькую долю секунды здоровенный буфер под джойн в памяти. У меня что, два процесса должны договариваться, кто сейчас может заюзать общие пять гигов, а кто будет ждать? И это всё через IPC? Да на кой мне это надо, такие лишние тормоза?
То что ты не знаешь, что такое mmap я уже понял, то что ты так и не понял, что процессам НЕ НУЖНО договариваться, потому что данные разделены по ключу - я тоже понял.

Ну что, ты не читаешь или не понимаешь то, что тебе пишут - тоже понятно, ну что с тебя взять?

iv_an_ruСхему БД тоже будем шардить? Хранимки? Юзеров с их полномочиями? Все конфиги и всю топологию кластера? Этого добра может быть дофигища.
Все статичные данных загружаются стартовым процессом сразу в память, помечаются как R/O, а после fork эти страницы памяти разделяются между всеми порожденными копиями основного процесса, разделяются, а не копируются - учи основы. Хранимки? Ок, если считать под хранимками обычный C код, который обрабатывает dbm базу данных - то код "хранимок" также хранится в одной физической области памяти, которая R/O и шарится между всеми шардами - опять учи основы.

iv_an_ru У меня прям сейчас в одном примере приходится держать в памяти 50 млн только access control list-ов, они жаты пережаты, а все равно гиг на ноду, одно только их активное подмножество изрядно портит настроение кэшу, а если их на 12 помножить, то кластер будет занят не работой, а проверкой полномочий.
Еще раз, ты или прикидываешься идиотом, или я даже не знаю, как тебя еще называть

50 млн acl в случае шардинга на 16 нот разделяются на секции по 50/16, хеш ключом, т.е. на одной шарде хранится по 3.2 миллиона, а не по 50. Иди почитай еще раз статью про шардинг, хватит уже тупить.


iv_an_ruСтранно, а чем же я тогда занимаюсь-то?
Похоже какими-то страшно кривыми провинциальными глупостями. Хотя оно у тебя все как-то работает, и ладушки, но ничего интересного ты пока даже близко не рассказал, разве про типовые заблуждения из древних тупиковых архитектур понарассказывал.

vromanovМы мешаем С и С++. С++ там, где нужна типизация, динамические массивы итд.
С в остальных местах. Потоки не используем, вместо них процессы. Обмен данными через mmap.

В C есть типизация - структуры.Gприсваивать структуры разных типов запрещено, при переприсваивании указателей несовместимых типов - компилятор генерятся warnings как минимум. В общем по C++ незачет.

Динамические массивы на C есть с 70х годов - изучите уже realloc. Незачет в квадрате.

iv_an_ruЕщё раз. _Не_все_ данные разумно пилить между нодами. _Не_все_ задачи сводятся к толпе юзеров, которые флудят на фейсбуке, никак кроме спама друг с другом не связаны и шардятся как угодно.
Приведи пример задачи. Пока ты привел acl - там как раз тупейшее пиление именно по юзерам.

iv_an_ruУвы, в жизни это не статические данные, да и хранимки не на сях пишутся и не раз навсегда.
Кофигурация кластера - это именно статические данные. Если вы не умеете делать кластеры и писать хранимки на сях...
Ну это лишь показывает ваш уровень "развития", гордиться нечем.

iv_an_ruА что, уже придумали шардинг по зависимым полям, не только по ключам? Или каждую выборку из защищённой колонки таблицы надо будет снабдить лишним распределённым джойном ко всем нодам, в которых лежат секции ACL? Кто, спрашивается, прикидывается здесь идиотом?
Господи, что за тупость? Какие еще нахрен джойны? Что с чем джойнить? ref_id в name для справочника на SQL?
Вы там реально мохом позарастали. Откройте для себя уже денормализацию, право.

iv_an_ruНу древние. Ну тупиковые. Правда, вы начали с того, что поставили mysql в пример,
Это не пример, а лишь образец проекта на C. С вкраплениями гамнокода на C++, как выяснилось довольно быстро.
Впрочем, я mysql не пользуюсь, так что мне на это все до лампочки.

iv_an_ru а мы его почему-то регулярно и по скорости делаем и тем более по функционалу.
Кто это мы?

Что вы там делаете? У меня модифицированный dbm отрабатывает 450к записей в секунду на запись в одной ноде и примерно 800к на чтение, и? mysql на этой задаче барахтался с показателем 3к и 7к, тоже мне невидаль.

Только идиот сейчас станет использовать SQL подобное для нового проекта для highload

vromanovПроясним ситуацВ C есть типизация - структуры.Gприсваивать структуры разных типов запрещено, при переприсваивании указателей несовместимых типов - компилятор генерятся warnings как минимум. В общем по C++ незачет.

Динамические массивы на C есть с 70х годов - изучите уже realloc. Незачет в квадрате.
В с нет нормальной типизации для перечислений, а нам это важно.
Скажем так - вам хочется верить в то, что вам это важно.

vromanovреалок это не динамический массив, это всего лишь возможность изменить рамзер выделенного буффера. Чтобы это стало ТИПИЗОВАННЫМ динамическим массивом надо очень много навертеть.
Ага, очень, очень много

myarr = (*myarr_t) realloc(myarr, ....)

НУ ОЧЕНЬ, ОЧЕНЬ МНОГО

vromanov Пока с этой работой лучше справлется vector<>. У него етсть свои недостатки, но для нас они не кртичны. В планах есть избавиться от них, но уж точно не перйти на realloc

Смешно и печально. С++ мозга такое C++.

vromanovmyarr = (*myarr_t) realloc(myarr, ....)

НУ ОЧЕНЬ, ОЧЕНЬ МНОГО

Детский сад..

Это все, что ты способен сказать?

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

Приведи пример задачи. Пока ты привел acl - там как раз тупейшее пиление именно по юзерам.Не, в теории-то можно и распилить. Если не интересует скорость в результате. Потому что в той задаче все остальные данные никаким боком _не_ шардятся по юзерам.
Приведи пример данных, которые не шарятся.

Вопрос #2 - что мешает их, эти данные, расшрить через mmap (MAP_SHARED), просто тупо загрузив из базы данных в разделяемую память?

iv_an_ruЗа аптайм в кластере несколько нод успеют сдохнуть, все машины в очередь запросто сходят на апгрейд, а часто ещё и количество машин удвоится. Про схему и хранимки даже не заикаюсь. Ну очень статические данные.
Ты или в очередной раз решил продемонстрить свое "слышал звон", или... даже уже не смешно.

Откройте для себя carp/ucarp/VRRP или HSRP. Конфигурация кластера - статична, и предопределена заранее. Если падает нода - резервная автоматом встает заместо нее, пока блейд меняют. Плюс ноды заранее создаются прореженными, фактически один шард обслуживает несколько IPников, при перебалансировке - просто шарда сплиттится автоматом (данные предварительно копируются на новую ноду).

Вот уже позорище, ёмое. Динамическая конфигурация кластера - это пять. В фортунки навечно!

архЕткторы блин.

iv_an_ruПроясним ситуацЕсли вы не умеете делать кластеры и писать хранимки на сях...Сколько будет стоить написать на сях эквивалент одного хотя бы 20-килобайтного скуля? А хранимки с десятком таких запросов? И не устареет ли эта хранимка за время её написания? А если это ad-hoc запрос, то не помрёт ли пациент, пока вы напишете (и отладите!) запрос, который из всех медкарт отберёт случаи с наиболее похожими томограммами черепушки и выдаст чем лечили и что получилось?
Еще раз - не умеете делать высоконагруженные базы данных, пишете хранимки на SQL - гордиться нечем.
Стыд и срам по перфомансу и не только.


iv_an_ruПроясним ситуацВы там реально мохом позарастали. Откройте для себя уже денормализацию, право.Вы не поверите, мы в курсе про денормализацию. Только, опять таки, знаем, когда и где её надо применять, а когда --- нет.
Судя по джойнам, которые упоминаются уже пятый раз - вы там походу НИХРЕНА не знаете.

А если и знаете - то уж точно применять знание не умеете.

iv_an_ruНу и сколько кверимиксов в час он выдаст на BSBM? А сколько покажет на TPC-H? Нисколько? Тогда зачем устраивать пузомерку c RDBMS?
Мне откровенно плевать на TPC-H. Я только знаю, что вместо 200 серверов на mysql у меня работает всего два, остальное мне - глубоко до лампочки.

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

95% населения - идиоты. Это ни для кого не секрет.


----

Чувак, ты реально утомил. Оригинальные мысли у тебя будут или нет? Те глупости, что ты "вещаешь" - мы прошли уже лет пять назад.

Расскажи хоть что-то новое, а?

vromanovне помогает. Т.к. типы host_ip_t и net_ip_t будут соместимы. Можно обернуть в структуры.. Но это будет через жопу. Есть другие решения?

Т.е. через классы и темплейты - это не через жопу, а через структуры - через жопу?

Извини, я не настолько спец по жопам.

Edd.DragonМне вот искренне интересно, с какого перепугу профессионал будет строчить столько буквов в каких-то там форумах ради убеждения себя в своем профессионализме?

Или есть другие цели всего этого детсада?
Это просто верификация подходов на обычных смертных. Вернее, в данном случае - оценка их реакции, когда вместо 200 серверов им предложат технологию, которая позволит оставить всего 2, правда придется прочитать мануал на 50 листиков.

Пока результаты печальны - простые смертные настолько зашорены и зашуганы, что починить им разум просто так не получится.

Edd.DragonУ меня, к примеру, предел в 3-4 содержательных поста в адрес троллей в сутки. Дальше уже времени жалко.
У тебя вообще нет ни одного хоть как-то осмысленного поста. Ты лишь генеришь бессмысленный и никому нафиг не нужный информационный шум.

Edd.DragonА тут прям пишет и пишет не покладая рук. Неужели настолько сомневается в себе? Это ж печаль и повод обратиться к психологу.
Обратись сам, заодно выяснишь - на кой хрен ты постаешь тут на скуль свои нафиг никому не нужные "мысли."


Edd.DragonЧувак, ты реально утомил. Оригинальные мысли у тебя будут или нет? (с)
У меня все мысли - оригинальные. Это у тебя просто разум настолько незрел, для тебя все это это лишь "блаблабла".

Так не для тебя пишется, любимого. Иди лучше телик посмотри, под пивас.

iv_an_ruПотому что все они в память тупо не влезут, а надеяться на то, что ОС вслепую, не зная специфики приложения, исхитрится правильно спланировать вытеснение дисковых буферов на несколько физических томов (и закачку нужных с тех же томов) --- очень наивно.
Еще раз. Ты читал man mmap?

Ну пойди прочитай. Отображенный в память файл - это не буфер, и уж тем более не файловый и не дисковый буфер.
Про madvise ты как я понял тоже - даже не попытался почитать руководство.

Это пять. Профессионализм видно невооруженным взглядом.

iv_an_ruУвы, нужна именно реальная конфигурация, потому что читать надо поровну со всех копий ноды, а писать --- на все разом, при этом обеспечивая правильную транзакционную семантику.
Походу ты даже не прочитал, что это такое UCARP/CARP. Опять попадание в десятку. Очень приятно рассказать человеку о полетах в космос, а он тебе отвечает, ну да, дескать у него картошка не взошла в этом году, потому самогон не удался....

iv_an_ruЭто ответ на вопрос "сколько...". Понятно.
Господи, что тебе понятно? При наличии библиотеки поверх dbm манипуляция курсорами и выборками занимает столько-же кода, сколько и на PL/SQL, T-SQL, и даже меньше. Так устроит?

iv_an_ruА что, реляционную алгебру уже отменили? Теперь положено просто хранить базы готовых ответов на все случаи жизни? Увы, это не всегда возможно, потому что нет списка готовых вопросов.
Нет, теперь положено хранить таблицы уже денормализованные, в случае документ-строка - уже сразу кластеризованные (документ и строки в одном блоке данных), а не джойнить их каждый раз со справочниками и между собой.

Не знал? Ну джойнь дальше, тыж не зря SQL выучил, ага.


iv_an_ruПроясним ситуацпропущено...
Мне откровенно плевать на TPC-H. Я только знаю, что вместо 200 серверов на mysql у меня работает всего два, остальное мне - глубоко до лампочки.Если вам глубоко до лампочки, чем занимаются другие люди, то зачем вы их пытаетесь учить?
Я не собираюсь никого учить. Сейчас я понял предельно четко - что для того, чтоб вбить тебе в голову знания о подходе, который
замещает 200 сервров двумя - нужно нанимать специально обученных людей, вбивателей знания в голову.

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

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

iv_an_ruПроясним ситуац95% населения - идиоты. Это ни для кого не секрет.Пока что секрет --- входите ли вы в оставшиеся 5%, или мы с вами вместе составляем интеллектуальное большинство.
Правило 95% универсально. С т.з. квантовой физики лично я - беспросветный идиот, и не только с точки зрения физики.

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

iv_an_ruПроясним ситуацРасскажи хоть что-то новое, а?Нафига? Вам же "откровенно плевать" и "глубоко до лампочки".
А ты просто попробуй, сначала. А потом мы уже решим - будет мне плевать или нет.

Или вот этими десятками уже постов - ты пытался мне дать некое новое знание или истинно верное?

Ой, извини, не оценил....

Edd.DragonНо если ты не хочешь, чтобы тебя слушали, для кого тогда вещаешь?!
Я не хочу чтобы меня слушали. Я хочу что бы мне дали развернутый ответ - почему тот или иной тезис является неверным.
Да. Чтобы меня самого назвали глупцом, потому что... (далее идет список).

Edd.DragonУгу. Вот я спрашивал о твоих достижениях, чтобы сложить мнение о твоей компетенции, а ты сделал вид, что не заметил.
Да, я не считаю нужным тебе на это отвечать. Мне не нужно признание моих достижений - мне нужна лишь верификация пары тройки идей, на счет которых у меня есть сомнения.

Edd.DragonНу и с фига ты тут взялся кого-то чинить, если пока что ты никто и звать тебя никак?
Естетсвенно, что с таким подходом ты не увидел ни одного "О чувак! Дело пишешь!".
Можно даже допустить, что дело думаешь, но пишешь явно не его. Самолюбованием занимешься.

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

А если ты привык пресмыкаться перед "авторитетами", то что же- пресмыкайся дальше, но мне с тобой точно не по пути.


Edd.DragonЯ захотел обратить твое внимание на это - обратил. Тебя не устраивает сказанное - твоя проблема. Можешь попробовать еще разок уколоть меня в ответ. И продолжать игнорировать вопросы в лоб, а отвечать только на те, которые тебе по зубам. Так обычно и поступают истинно оригинальные спорщики.

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

Так доходчиво?

iv_an_ruПроясним ситуацпропущено...
Еще раз. Ты читал man mmap?Да разумеется. Ну и дальше-то что? Управлять 384 гигами ОЗУхи в виде маленьких страничек? А TLB не лопнет? MAP_HUGETLB не предлагать.
TLB не лопнет, как минимум при 32 гигах не лопается. А так да - HUGETLB никто не отменял.

iv_an_ruПовторяю. "обеспечивая правильную транзакционную семантику". Я уж молчу про "пользу" лишней пофигени между отправителем и получателем.
Что такое транзакционная семантика, если пользователь долбится всегда в строго определенную ноду (которую лишь могу замещать временно другие ноды при выходе из строя)?
Про пофигень - вообще мимо, клиент сам знает в какую ему ноду долбиться (там только первая страница общая, дальше AJAX код уже знает номер "своей" ноды). В общем опять "звон колоколов".

iv_an_ruУх ты. А можно на эту библиотеку посмотреть?
Clipper'87 помнишь? В соврменной редакции harbour. Вот там примерно такое, в части API.

iv_an_ruЧтобы и выбирала всё сама, и группировки-сортировки-аггрегаты все сама делала, и execution plan сама строила?
Ты опять решил рассказать, что понятия не имеешь про денормализацию данных? Ну так поясним еще раз. Все группировки делаются заранее, считаются и сохряняются в базу. Данные хранятся в уже сортированном виде, готовом для отдачи клиенту без какой-либо обработки. А execution plan для операции SELECT * FROM DOCUMENT WHERE DOC_ID = :ID и даром не нужен - там просто лукап по хеш ключу.

iv_an_ruЧто-то мне подсказывает, что как раз скуль и получится, только кастрированный, с одним как бы универсальным типом хоронилища данных на все случаи жизни. Выборка из хэш-таблицы по диапазону ключей интересует особо, кстати :)
SQL и реаляционная модель - это такое-же кривое убожище, как и pthreads и ООП.
"Гения", который придумал разбирать данные и собирать при каждом чтении - нужно удостоить премии Дарвина.

iv_an_ruПроясним ситуацСейчас я понял предельно четко - что для того, чтоб вбить тебе в голову знания о подходе, который
замещает 200 сервров двумя - нужно нанимать специально обученных людей, вбивателей знания в голову.Я с радостью безо всякого вбивания выучу способ заменить кластер с 200x192Gb ОЗУхи кластером 2x192Gb. Пусть даже 2x384Gb, мне не жалко. Если я узнаю способ, как в них сложить активное подмножество с 200x1Tb дисковой памяти, я вмиг стану миллионером. Ради этого стоит постараться.
Ну так открой для себя data-life-cycle. 90% данных в твоем кеше наверняка вообще не используются (читается только одна строка из блока, остальные сидят в памяти за компанию, ибо размер блока), вы просто видать не можете сделать грамотное разделение по userid|timestamp секциям, чтоб вытолкать никому не нужные данные из памяти и никогда их туда не грузить, без явного запроса их.


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

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

Edd.DragonавторЛично мне глубоко плевать на какой-то там статус.
Не заметно

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

iv_an_ruскажем базу всех известных последовательностей ДНК для всех известных белков по userid|timestamp секциям. Один из самых популярных запросов --- некое подобие "регэкспа" по ДНК. Или как разделить дибипедию --- выжимку всех формализованных данных из википедии. Или геоданные. И что делать с базой, в которой лежат все эти знания вместе, плюс ещё полсотни больших баз и несколько миллионов разрозненных мелких ресурсов? Я очень внимательно слушаю. Мы научились трамбовать более-менее удачные базы знаний в 7 байт на факт, теперь хорошо бы с вашей помощью научиться, как сделать RAM/HDD ratio 1/1000.

"Диспут" скатился в просто треп.

Любой здравомыслящий человек прекрасно знает, что универсальных решений не существует. Принципы проектирования, заточенные
под событийную модель данных (ebay, facebook, twitter, и всякие эти ваши 1c, биллинги и erp и подобное) - будут неприемлемы для
геодезии, моделирования термоядерных процессов или ДНК.

Требовать совместить оптимизацию и timeline, и sparsed, к примеру, структуры - не более, чем глупая демагогия и спекуляция - это все равно что на автомобиль прикручивать еще и гусеницы, и реактивный двигатель.

Короче, Иван, пилите свои acl на SQL базах, интересной беседы так и не получилось, а высмеивать зашоренность "традиционных" подходов мне уже надело.

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

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

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

[quot vromanov]Проясним ситуацпропущено...

Однозначно. Потому что это более безопастно, приведет к меньшему числу ошибок и в тоже время приведет к генерации такого-же кода как при использовании С

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

iv_an_ruПроясним ситуац Любой здравомыслящий человек прекрасно знает, что универсальных решений не существует. ..
Требовать совместить оптимизацию и timeline, и sparsed, к примеру, структуры - не более, чем глупая демагогия и спекуляция - это все равно что на автомобиль прикручивать еще и гусеницы, и реактивный двигатель.Я жирным выделил. Ну а теперь перечитайте топик, свежим взглядом. Сначала вы старательно убеждаете всех, что все должны писать так, как вы,
Все? Я старательно подчеркивал, что для 95% населения это всё - вообще не приемлемо.


iv_an_ruа кто пишет по-другому и предлагает сначала думать и выбирать, как писать --- идиот. Когда вам объясняют, что задачи вообще-то бывают разные, и спрашивают, как вашими любимыми средствами сделать что-то, вы бодро разворачиваетесь на 180, лицом к здравому смыслу.
Сделать что? Хранение ДНК в реляционной базе данных? Это называется разворот к здравому смыслу? Атас.

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

iv_an_ruOoCcпропущено...

Это подход типичного "developer". Выглядит так что вы (ваш архитектор) просто не знаете что вашим клиентам нужно.Ага. Клиенты и сами заранее не знают, что им нужно. Простейший и самый популярный пример: торчит в веб точка доступа к толстой базе, любой желающий может отправить на неё какой угодно запрос, указать желаемый формат ответа, и получить этот ответ.

Самый популярный? Ну и где примеры таких сайтов? Хоть один, на котором деньги зарабатывают, а не играются? (apex.oracle.com показывать не надо).

iv_an_ruПроясним ситуацСделать что? Хранение ДНК в реляционной базе данных? Это называется разворот к здравому смыслу? Атас.С нетерпением жду лучших идей.

Обратитесь к специалистам.

алгоритмы кэшированияПроясним ситуацпропущено...

Еще раз. Ты читал man mmap?

Ну пойди прочитай. Отображенный в память файл - это не буфер, и уж тем более не файловый и не дисковый буфер.
Про madvise ты как я понял тоже - даже не попытался почитать руководство.
Вы просто друг друга не поняли. В любом случае, при использовании mmap, если файл больше ОЗУ, то в ОЗУ хранится (кэшируется) только его часть. И в любом случае кэшу приложения/субд/... лучше знать, что держать в кэше, а что вытеснять, чем кэшу ОС/ФС/...
Поверьте, внутренние алгоритмы кэширования СУБД очень сложны и во многих случаях способны дать прирост скорости доступа до 10 раз, по сравнению с любыми внешними по отношению к ней.

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

Это наверное так трудно - сдалать man madvise, да?

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 гигов ОЗУ.

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