Предположим, что у нас есть Postgres, Kafka и Elastic. В Postgres живет сущность, например, item.
Иногда возникает необходимость создать поисковый индекс отдельно от основной базы.
Например, если мы не хотим обрушивать поисковый трафик на Postgres мы можем вынести данные из него в Elastic.
Мне понравился опыт прошлого расследования по фейсбуку, и я решил организовать очередную серию, теперь про Amazon. Для нетерпеливых — в самом конце статьи описан итоговый вариант архитектуры Amazon S3 и проанализированы его свойства.
Не так давно Амазон объявил о переходе S3 с модели eventual consistency на strong consistency, то есть, предоставления гарантии read-after-write, чтения того, что было только что записано. Сообщество отреагировало, но как-то очень вяло: Amazon S3 Now Delivers Strong Read-After-Write Consistency
Первое, что лично мне подумалось в ответ на эти новости: а как же теорема CAP? Читать полностью »
Привет! Меня зовут Ксения Якиль. Я пишу core-сервисы на C и Go в бэкенд-отделе Badoo и Bumble. Наш бэкенд — это высоконагруженная распределённая система, обслуживающая пользователей по всему миру. Она оперирует большими массивами данных и делает всю ту магию, благодаря которой люди находят друг друга.
В прошлой статье цикла мы познакомились с типами биржевых заявок. Сегодня мы разберем книгу ордеров, обработку заявок и вопросы связанные с организацией хранения торговой информации.
С ростом количества компонентов в программной системе, обычно растёт и количество людей принимающих участие в её разработке. Как следствие, для сохранения темпов разработки и простоты сопровождения, подходы к организации API должны стать предметом особого внимания.
Если хотите познакомиться поближе с тем как команда Wargaming Platform справляется со сложностью системы из более чем сотни взаимодействующих друг с другом web-сервисов, то добро пожаловать под кат.
Читать полностью »
В прошлой статье мы рассматривали ограничения и препятствия, которые возникают, когда нужно горизонтально масштабировать данные и иметь гарантию ACID-свойств транзакций. В этой статье рассказываем о технологии FoundationDB и разбираемся, как она помогает преодолеть эти ограничения при разработке mission-critical приложений.
FoundationDB — это распределенная NoSQL база данных с ACID-транзакциями уровня Serializable, хранящая отсортированные пары ключ-значение (ordered key-value store). Ключами и значениями могут быть произвольные последовательности байт. У неё нет единой точки падения — все машины кластера равноправны. Она сама распределяет данные по серверам кластера и масштабируется на лету: когда в кластер нужно добавить ресурсов, ты просто добавляешь адрес новой машины на конфигурационных серверах и база сама подхватывает ее. Читать полностью »
Небольшой вопрос/ответ:
Для кого это? Людям, которые мало или вообще не сталкивались с распределенными системами, и которым интересно увидеть как они могут строится, какие существуют паттерны и решения.
Зачем это? Самому стало интересно что и как. Черпал информацию с разных источников, решил выложить в концентрированном виде, ибо в свое время сам хотел бы увидеть подобную работу. По сути это текстовое изложение моих личных метаний и раздумий. Также, наверняка будет много исправлений в комментариях от знающих людей, отчасти это и есть целью написания всего этого именно в виде статьи.
Как сделать чат? Это должно быть тривиальной задачей, наверное каждый второй бекендер пилил свой собственный, так же как игровые разработчики делают свои тетрисы/змейки и т. п. Я взялся за такой, но чтоб было интереснее он должен быть готов к захвату мира, чтоб мог выдерживать сотниллиарды активных пользователей и вообще был неимоверно крут. Из этого исходит ясная потребность в распределенной архитектуре, потому что вместить все воображаемое количество клиентов на одной машине — пока нереально с нынешними мощностями. Заместо того чтоб просто сидеть и ждать на появление квантовых компьютеров я решительно взялся за изучение темы распределенных систем.
Стоит отметить что быстрый отклик очень важен, пресловутый realtime, ведь это же чат! а не доставка почты голубями.
%рандомная шутка про почту россии%
Использовать будем Node.JS, он идеален для прототипирования. Для сокетов возьмем Socket.IO. Писать на TypeScript.
И так, что вообще мы хотим:
Как мы это хотим:
Как всегда, спасибо Фреду Хеберту и Саргуну Дхиллону за то, что прочли черновик этой статьи и предложили нескольких бесценных советов.
В своем докладе о скорости Тамар Берковичи из Box подчеркнула важность проверок работоспособности при автоматическом аварийном переключении баз данных. В частности, она отметила, что мониторинг времени выполнения сквозных запросов, как метод определения работоспособности базы данных, — лучше, чем простое эхо-тестирование (пингирование).
... перебрасывая трафик на другую ноду (реплику), чтобы устранить бездействие, надо построить средства защиты от дребезга и других пограничных ситуаций. Это не сложно. Фокус при организации эффективной работы в том, чтобы знать, когда перевести базу данных в первую позицию, т.е. надо быть в состоянии правильно оценить работоспособность базы данных. Сейчас многие параметры, на которые мы привыкли обращать внимание, — например, загрузка процессора, время ожидания блокировки, частота ошибок, — являются вторичными сигналами. Ни один из этих параметров на самом деле не говорит о способности базы данных к обработке клиентского трафика. Поэтому, если используете их для принятия решения о переключении, можете получить как ложноположительные, так и ложноотрицательные результаты. Наше устройство проверки работоспособности фактически выполняет простые запросы к узлам базы данных и использует данные о выполненных и невыполненных запросах для более точной оценки работоспособности базы данных.
Я обсудила это с другом, и он предположил, что проверки работоспособности должны быть предельно простыми, и что реальный трафик — это лучший критерий для оценки работоспособности процесса.
Привет всем!
Сегодня мы хотели бы в очередной раз затронуть тему одновременного и последовательного выполнения в различных программах, особенно — в распределенных системах. Еще в сентябре мы публиковали статью "Синхронность — это миф" на эту тему, а теперь публикуем перевод более серьезного исследования, которое, надеемся, поможет вам лучше сориентироваться с распределенными системами.
Читать полностью »
Когда приложение было монолитным и вдруг, раз, стало распределённым, в формулу вычисления доступности добавляется ещё одна неизвестная — сетевая. Из-за проблем с вызовами между компонентами, приложения часто валятся и начинают дрыгать ножками. А выяснение причин нестабильной работы распределённого приложения — та ещё задачка. Дополнительную неразбериху в структуру приложения вносит условный kubernetes, который по своему внутреннему усмотрению может произвольно распределять условные поды по условным нодам. Пишу «условный», потому что на месте kubernetes может быть и Swarm и Openshift и прочие и прочие.
Я к тому, что без нормальной визуализации разобраться где температурит, может быть очень непросто. Под катом моё представление о потенциальных возможностях инструментов, которые умеют рисовать карту приложения и подсвечивать места для прикладывания подорожника, а также список этих самых инструментов со скриншотами.
Читать полностью »
