![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
ermouth6 недель назад я нарисовал вот такую вот черновую схемку высокопроизводительной масштабируемой CMS (Коммент для понимающих: тут хреново названо только. Frontend – это общедоступная часть сайта, Backend – админка. Пользователи – на концах зелёных стрелок, за схемой, есличо).
Так вот, оно взлетело, да ещё как. Результаты по скорости рендера на Амазон EC2 medium (3.8 Gb RAM, проц примерно как Core2 Duo 1.5Ггц и диск как медленный SSD) вот такие:
Это неделю назад, сейчас ещё быстрее. Это случайный рендер по множеству из 112500 урлов. С выборкой из БД. Более 90% страниц предполагают выборку более 50 публикаций перед рендером целиком. С последующей группировкой и фильтрацией по тегам. И с расстановкой переносов )
На реальных условиях (с запросом и ответом в gzip) тоже оттестировано. С учётом пинга до Архангельска любая страница при нагрузке до 50 запросов в секунду в 99% случаев выдаётся менее, чем за 250мс. Если тестировать прямо с ирландского амазона с нагрузкой 100 страниц в секунду, получается “менее, чем за 20мс”.
Фактически на запросы из Архангельска сервер в Ирландии начинает отвечать через 100 мс, то-есть примерно через 120 мс при наличии скриптов/css в кэше браузера начинается рендер страницы.
Если по-русски, оно летает просто )
И это полностью, до последней строчки, javascript (скептики, утритесь). При этом оно чистый, не прошедший даже черновую оптимизацию, говнокод (утритесь снова ггг).
Я знаю, на фленте есть френды, которые прямо сейчас делают что-то подобное. И тоже функциональщина. И тоже nosql, и с прицелом на highload и лёгкую масштабируемость. Присоединяйтесь )
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2013-05-04 09:30 pm (UTC)no subject
Date: 2013-05-04 10:12 pm (UTC)Для меня Монго это такое "ни два, ни полтора". nosql-субд, не дающая никаких особых преимуществ против SQL в моих сценариях.
По пунктам про КучДБ.
– Куч версионирует документы...
– ...это значит, что нет блокировок, при записи запросы на чтение получают просто предыдущую версию,
– ...это значит частичную отменяемость без транзакций,
– ...это означает практически гарантированное выживание базы при любых падениях на любой стадии (это проверено).
– Документы – чистый json.
– Куч хранит аттачи рядом с документами, это очень круто – для CMS самый частый сценарий как раз написать пост с аттачами. Ну то-есть в хранимом доке появлется системное поле _atatchments, где они все перечислены – ссылки там на них, размеры, версия, MD5, состояние, майм)
– Куч сразу содержит веб-сервер и усправляется простыми REST-запросами по http(s). Парметры запроса в json.
– Куч умеет прямо из коробки в два клика делать непрерывную мастер-мастер репликацию между БД по http, с контролем версий (как доков, так и аттачей к ним) и конфликтов.
– Куч умеет это делать между несколькими узлами одновременно и по сложной выборочной схеме.
– У Куча есть REST-интерфейс, позволяющий подписаться на определённые обновления в базе longpoll'ом, типа push-обновлений будут приходить.
– Куч не просто key-value, в него встроена механика выборки map-reduce, причём результаты расчёта map-функций для каждого узла кэшируются в B-tree и выбираются очень быстро. Это аналог многоуровненвых связных индексов.
– По индексу может выдаваться не документ целиком, а только его часть или даже результат каких-то вычислений над документом, это всё тоже кешируется.
– Эти функции пишутся на javascript.
– У Куча изумительная встроенная панель управления через браузер.
– Поддерживается role-base и per-user security на уровне подборок доков (но не отдельный доков, но это легко решается).
Недостатки:
1. _только_ http(s) запросы к базе – это как минимум значит чудовищный по сравнению с другими базами overhead на сериализацию json-дока и проход запроса через веб-сервер.
2. Append-only writes приводят к быстрому росту БД, особенно при неправильной организации и частых операциях замены документов.
Первый недостаток решается правильным проектированием (читать сразу по-многу, формировать сложные collated-индексы). Второй недостаток делает КучДБ непригодным для хранения, например, логов запросов к серверу или статистики, накапливаемой в реальном времени.
no subject
Date: 2013-05-04 11:04 pm (UTC)про складирование данных в реальном времени, я в свободное время занимаюсь штукой (http://ljtop.jit.su/), которая парсит твиттер на жж посты и складывает в монгу, собирает статистику по шеарам. хочу потом прикрутить простой анализатор текстов. у меня здесь одна коллекция и твиты лежат embed-доками внутри каждого поста. в кауче поступают так же?
no subject
Date: 2013-05-04 11:31 pm (UTC)я бы создавал:
1. док поста, эмитил бы мап-функцией по нему ключ [post_url, -post_timestamp]
2. док твита, эмитил бы с ключом [post_url, -twit_timestamp]
А потом бы выбирал это по диапазону ключей [posturl, null] — [posturl, 0]. И на выходе сразу получал бы отсортированный список твитов по времени плюс сам пост первым элементом списка.
Если выбрать по диапазону ключей ["", -end] — ["\ufffe", -start] мы получим все и посты и твиты за нужный период времени, хотя для этого лучше создать отдельный view и внедрять в него ключами только значение -post_timestamp или -twit_timestamp.
Разными мап-функциями можно делать очень хитрые индексы. По юзеру там, по тэгам и тп. Составные, реверсивные – всякие.
Замечу, что этот подход как раз в полной мере подходит под append-only запись. Я не создаю версии документов (как если бы писал твиты в аттач к посту), а дописываю доки в конец базы.
no subject
Date: 2013-05-04 09:51 pm (UTC)Мне очень нравится вообще сам факт, что ты оптимизируешь client performance, ну и результаты тоже!
*) Расскажи про масштабируемую поддержку фидов - ну или любых других объектов, которые нельзя тупо шардить по юзеру и получать хороший скалабилити, типа, ты где-то поменял, должно ещё в 500 местах сразу измениться.
*) Что такое replication CouchDB на клиенте? Это просто кэш запросов, живущий между перезапусками браузера, или что-то больше?
*) Конкретно с CouchDB я ещё не работал, но be aware of issues: http://sauceio.com/index.php/2012/05/goodbye-couchdb/
no subject
Date: 2013-05-04 10:28 pm (UTC)Клиент для обоих частей – это браузер. Он на верхних концах зеленых стрелок. А в облаке – это либо один, либо два инстанса на амазоне.
Ссылка у меня твоя фиолетовым показывается – я это читал прошлым летом, когда как раз остановился на КучДБ. Текущая версия 1.2.1, есть 1.3 на http://www.iriscouch.com/. Это всё решено уже.
Про масштабируемые фиды – это не отсюда задачка, но я знаю, как её решать. У меня вот внутри офиса решено, как раз на КучДБ кста, хотя и мудрёно. Работает с начала года ) Я сейчас умею и попроще, и побыстрее.