asd111: facebook старается читать из кэша только по причине 4 милиардов rps в тот самый кэш, в любом случае запихивание данных в кэш это последнее что можно делать, т.к. гемороя оно доставляет.
В большинстве случаев использование эластика/сфинкса и прочего полностью не оправданно, т.к. все считают что на их данных какой-то там хайлоад, а на самом деле его нет, СУБД легко справится, + делают так потому что не знают что СУБД может немного больше чем строки по PK доставать, вот и городят зоопарк. Современные СУБД легко обслуживают десятки тысяч транзакций в секунду, что для большинства чуть более чем достаточно, вопрос в другом, многе могут положить сервер с 10 запросов, поэтому пытаются перенести проблемы с больной головы на здоровую, проще из БД в эластик/сфинкс
не вводите людей в заблуждение, никуда и никто не идет в сторону "БД только для записи" - это иррационально и решение "засунуть данные" еще куда-то далеко не проще чем просто работать с БД
короче, у вас есть клиент у которого что-то там написанно на ноде, оно работает в одном процессе и "это боль", клиент хочет "быстро" и не требовательно. Вы ему предлагаете, хотя нет, не предлагаете, вы пока не знаете как, но что-то сделать. Предлагаете вы следующее: в итак "шатко-валко" работающую систему запихнуть еще одно звено, которое потенциально SPOF, в этом звене вы что-то хотите запихнуть в память чтоб оно отдавало быстрее, при том что там GC, ок, в том же звене, которое не особо может "достучаться" до ядра ОС вы хотите принять tcp соединение, "нежно" его передать в совершенно другой процесс и при этом его не разорвать, причем после передачи "схлопнуть" соединение со "звеном", ок
что вам предлагают, теоретически:
* взять проверенное решение для балансировки nginx, т.к. он L7, то позволяет нафигачить логики проксирования чуть более чем достаточно
* поднять n-е количество процессов на node.js
* отдавать данные темже балансировщиком, ну охота вам в пямять что-то засандалить и отдавать оттуда, пихните ее в tmpfs и синкайте когда надо
* 20к онлайна это хорошо, но вот такими решениями "выжать" что-то из железа, хм. О sysctl слышали, вот туда копайте чтоб из железа выжимать, а то оно в "линуксах" под "пылесос" заточено (самый минимум)
* издержки nginx по памяти и скорости на соединение ничтожно малы, о них даже говорить не стоит. "Скорость" на проксировании падает только тогда, когда соединение постоянно нужно открывать (резолвы, хендшейки. теоретически), в случае уже открытого оно вообще "ниочем"
Alzasr: скорее всего, он их не сразу закрывает, т.к. "пулит" коннекты, я точно не знаю нужно код mysql рыть, давно с mysql не "общался". Вообще там по коду у них видно что они что-то да переписали ,месяца 3 назад, (попробуйте на последнем), а так бардака навалом.
Нодар: dns кэшируется, большенству провайдеров наплевать на ttl, соответственно если у вас адрес "выпадет", то часть пользователей - "привет", еще есть Windows в нем свой кэш dns, ff и chrome на него наплевать, у них свои, а вот ie им пользуется, дак вот их кэш dns в случае round robin пытается найти "самый короткий" маршрут, и вам в 1 ноду могут "прилететь" все пользователи ie, ну и так куча всего по мелочи
bingo347: дак это aлгоритм маляра Шлемиля ) Во первых кэширование статики отдайте на nginx, во вторых в томже nginx есть lua-upstream-module (https://github.com/openresty/lua-upstream-nginx-module, а сейчас и nginScript) для вашей логики условия распределения новых сессий.
djay: ну 1 000 000 одинаковых запросов в секунду никого не интересует, а вот от переписывания всех что есть тот самый датамапер не спасает, ну да ладно. Я рад что когда у вас когда возникает ситуация: "обычно когда что-нибудь с хайлодом или смежными областями" вы находите ответ на СерверФолт.ком, это здорово что специалист, или как вы выражаетесь " вменяемый чел", находит время что-то там объяснить. За совет конечно спасибо, если вдруг мне приспичит что-то спросить, я им воспользуюсь ;)
djay: Каюсь, так и есть, не работал, пример с "выбрать книжку по id и удалить" впечатлил, правда вот не знаю как это поможет когда есть, скажем 1000-2000 запросов заточенных под конкретную РСУБД.
При этом использование примера выше, в силу того что ну вот нельзя взять проект и легким взмахом перенести, как бы избыточно, есть у меня метод который возвращает книжку по id GetBookByID() Book и SaveBook(Book) и гуд
Насчет примеров я не совсем уверен, т.к. особо ничего в пример и не приводил, однако и в поиске ответов на "StackOverFlow и Программерс.Стакесченг.ком" я тоже не особо уверен )
Ну, как бы они, пускалки тестов, в том или ином виде есть для любой СУБД, да и самому пускалку тестов написать не та уж и проблема
Чем оно поможет при смене СУБД, хотя "легкая" смена БД - это больше маркетинговый булшит, но все же
Вообще дастовляет само существование "паттерна" "Data Mapper", что оно вообще значит, то что другой "паттерн" будет говорить о том что: "объект книжка должен самосохряняться" ? Дак вот, если уж, к примеру, драйвер БД может мапить строки на объекты (невидаль такая), то, вам, что есть "хранимки" что их нет, нужно переписать свое "ПО" чуть более чем полностью чтобы влезть в другую СУБД. Повторюсь, проблематика смены СУБД есть и всегда будет и до момента "Х" о ней даже думать не стоит и если назвать функцию сохранения/извлечения данных из СУБД хоть датамапером, хоть еще чем - это не поможет. Однако, тут как бы все гуд, но, вот эти вот оглядки на легко/не легко, паттерны/не паттерны, нагрузка/не нагрузка приводят к тому, что возможности СУБД не используются вовсе. При всем при этом что любая современная "РСУБД" это такой "монстр" на стероидах который моэет обрабатывать десятки тысяч транзакций в секунду, но в "умелых" ручках сдыхает при 10 Гб данных и 100 запросах
Станислав Макаров: нет всмысле не видел, обычно люди не умеют работать с СУБД и скрывают это за ОРМ/ДАЛ и прочими аббревиатурами, либо умеют и там все более менее "ок", короче на практике такого небыло.
Монга достаточно неплахая штука и у нее есть своя ниша использования, одняко ряд особенностей не позволяют ее использовать там где нужна поддержка целостности и прочие прелести которые есть в современных (да и не очень) РСУБД, + внезапно она не такая гибкая как тотже Postgres
Станислав Макаров: это такая холиварная тема, СУБД = ACID, способности по C, ага, различаются, у нас на одном проекте MySql "доживает" вот там периодически появляются записи с foreign key "вникуда" и вообще куча "нежданчиков" )
1) pgTAP как пример
2) ха-ха-ха
3) "речь о веб-приложениях и масштабируемой архитектуре" и тут да, возможности РСУБД использовать зло, ибо они ататат, зато Data Mapper засунуть можно, "ок"
1. Нет, даже наоборот, просто тесты пишутся на sql и запускаются в БД
2. На другую БД в любом случае мигрировать проблематично
3. Давно РСУБД это просто "хранение данных" ?
посути экономия на построении плана запроса, он отсылается 1 раз, все последующие итерации отсылают только данные и сервер только "впихивает", а не парсит запрос и строит план выполнения