(начало здесь )

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

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

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

Проясним ситуацДва - шарды на то и шарды, чтобы иметь разделение по некому хеш ключу, говоря проще, каждая шарда хранит строго свои наборы данных, мапит свои файлы, и обслуживает строго свои группы клиентов, никаких конкурентных доступов там и близко не предвидится.Схему БД тоже будем шардить? Хранимки? Юзеров с их полномочиями? Все конфиги и всю топологию кластера? Этого добра может быть дофигища. У меня прям сейчас в одном примере приходится держать в памяти 50 млн только access control list-ов, они жаты пережаты, а все равно гиг на ноду, одно только их активное подмножество изрядно портит настроение кэшу, а если их на 12 помножить, то кластер будет занят не работой, а проверкой полномочий.

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

Проясним ситуацТы походу вообще выпал из струи прогресса и современных highload течений.Странно, а чем же я тогда занимаюсь-то?

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

Проясним ситуац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. Иди почитай еще раз статью про шардинг, хватит уже тупить.А что, уже придумали шардинг по зависимым полям, не только по ключам? Или каждую выборку из защищённой колонки таблицы надо будет снабдить лишним распределённым джойном ко всем нодам, в которых лежат секции ACL? Кто, спрашивается, прикидывается здесь идиотом?

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

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

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

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

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

Проясним ситуацЧто вы там делаете?Ну я ж не аноним, сами можете догадаться. Вы же гордились, что читать умеете.

Проясним ситуацУ меня модифицированный dbm отрабатывает 450к записей в секунду на запись в одной ноде и примерно 800к на чтение, и?Ну и сколько кверимиксов в час он выдаст на BSBM? А сколько покажет на TPC-H? Нисколько? Тогда зачем устраивать пузомерку c RDBMS?

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

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

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

Проясним ситуацiv_an_ruЗа аптайм в кластере несколько нод успеют сдохнуть, все машины в очередь запросто сходят на апгрейд, а часто ещё и количество машин удвоится. Про схему и хранимки даже не заикаюсь. Ну очень статические данные.
Откройте для себя carp/ucarp/VRRP или HSRP.Увы, нужна именно реальная конфигурация, потому что читать надо поровну со всех копий ноды, а писать --- на все разом, при этом обеспечивая правильную транзакционную семантику.

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

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

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

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

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