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, да?