Comments 58
Изначальную версию Discord написали быстрее чем за два месяца в начале 2015 года
Интересно как много человек участвовало в этом процессе. Production-ready приложение быстрее чем за два месяца — звучит вызывающе.
Мне кажется это был MVP который решили запустить в полностью боевом режиме и дальше понеслось само… Если дела примерно так и обстояли то как таковой фантастики в этом нет, но изрядная доля везения в таком случае была явно на стороне команды Discord, потому что цена ошибки при такому подходе — аудитория, а с учетом специфики самого сервиса — аудитория довольно капризная и не прощающая ошибок.
Когда нет легаси и все на энтузиазме еще и не такое возможно.
Павел Дуров: «Первую версию ВКонтакте в 2006 году я собрал за месяц».
не собираемся использовать шардинг MongoDB из-за его сложности и неизвестной стабильности
в статье не хватает практических подтверждений таких заявлений
Про монгу много слухов ходит (про потерю данных, нестабильность, etc), и вот в чем проблема — им нет опровержений. Вам есть что сказать на эту тему? Я думаю, не одному мне было бы интересно послушать контраргументы.
Вроды бы Афир наконец-то починил Монгу: https://jepsen.io/analyses/mongodb-3-4-0-rc3
Хотя вообще, полностью поддерживаю этот FUD по отношению к Монге, мое мнение — изначально настолько плохо написанные проекты баз данных не вытягиваются на новый технический уровень никакими заплатками и рефакторингами, кроме полного переписывания с нуля. Даже если сейчас они что-то починили, очень большая вероятность, что опять сломают в следующей версии. Если не баг в распределенной системе, так какую-нибудь регрессию по скорости схватят.
В интернете кричат, в основном пользователи с негативным опытом, хотя стоит признать, что до DocumentLevel lock все было очень печально, но и тут люди умело обходили проблемы.
Проблемы под нагрузкой есть у всех, но у MongoDB в свое время были слишком сильные фейлы, которые хорошо отложились в памяти (суточный downtime у Foursquare)
1) http://www.serverdensity.com в 2015 назад обрабатывал 350ТБ данных в месяц на шардированной MongoDB, причем время отклика было в среднем 40ms (на MMAPv1), чего уже говорить о WiredTiger.
2) CraigList, Disqus, но это все и так известно. Есть даже целый список из 4000 компаний по всему миру.
Сейчас, кстати, есть тенденция, что к Mongo возвращаются разочарованные и идет большой поток новичков, потому как детский ошибки пройдены и сейчас она выглядит очень неплохо
Проблемы под нагрузкой есть у всех, но у MongoDB в свое время были слишком сильные фейлы, которые хорошо отложились в памяти (суточный downtime у Foursquare)
1) http://www.serverdensity.com в 2015 назад обрабатывал 350ТБ данных в месяц на шардированной MongoDB, причем время отклика было в среднем 40ms (на MMAPv1), чего уже говорить о WiredTiger.
2) CraigList, Disqus, но это все и так известно. Есть даже целый список из 4000 компаний по всему миру.
Сейчас, кстати, есть тенденция, что к Mongo возвращаются разочарованные и идет большой поток новичков, потому как детский ошибки пройдены и сейчас она выглядит очень неплохо
Мне кажется ребята просто не хотели лишний раз рисковать превозмогая в случае чего. Это как если вы услышите статистику «самолеты авиакомпании N разбиваются значительно чаще чем у компании M», подсознательно будете при возможности стараться выбирать авиакомпанию с учетом этой информации, потому что цена ошибки может быть крайне высока даже если в реальности это не так или выбор стоит между одним к ста тысячам или одним к двухста тысячам случаев.
Возможно не самый красивый и правильный пример, но он помогает посмотреть немного под другим углом.
Возможно не самый красивый и правильный пример, но он помогает посмотреть немного под другим углом.
после недавней статьи про убер и его миграции с pg и его минусами в масштабировании, начал собирать инфу об альтернативных (хорошо забытых) вариантах. статья как нельзя кстати, спасибо.
Мне кажется чат надо хранить в JSON либо в другом сериализаторе. Или хотя бы XML.
1. Чат это текст, соответственно хранить как текст
2. Отправитель и получатель никогда не изменяются
3. Данные о дате сообщения никогда не изменяются.
так почему бы не хранить это статически?
В случае чата каждый с каждым — это не куча записей в базе по каждому сообщению, а только одна запись диалога… при чем даже не надо на стороне сервера что-то парсить, пусть делает JS и рисует на основе данных интерфейс.
и средствами самой базы легко, в случае JSON, делать как выборки, так и апдейты с инсертами.
1. Чат это текст, соответственно хранить как текст
2. Отправитель и получатель никогда не изменяются
3. Данные о дате сообщения никогда не изменяются.
так почему бы не хранить это статически?
В случае чата каждый с каждым — это не куча записей в базе по каждому сообщению, а только одна запись диалога… при чем даже не надо на стороне сервера что-то парсить, пусть делает JS и рисует на основе данных интерфейс.
и средствами самой базы легко, в случае JSON, делать как выборки, так и апдейты с инсертами.
Вы предлагаете работать на уровне локальной файловой системы без распределенности?
я предлагаю хранить текст чата в БД в виде JSON строки. Это логически правильно. Тем более базы умеет делать выборку по JSON, а некоторые не то чтобы обновлять отдельные поля, но и даже строить индексы по полям в JSON.
Если хранить каждое сообщение отдельно, как делают в статье, то если есть 10 чатов по 10 человек и каждый напишет в чат по одному сообщению, то это получится будет 100 записей. Если хранить диалог, то это так и останется 10 строк в базе, что на порядок меньше. А если количество пользователей и их сообщений будет увеличиваться арифметически, то количество строк будет увеличиваться геометрически. Поэтому и пришли к тупику как хранить миллиарды сообщений. Завтра им придется хранить 10 или 100 миллиардов сообщений и они опять придут к тупику как жить дальше.
Если хранить каждое сообщение отдельно, как делают в статье, то если есть 10 чатов по 10 человек и каждый напишет в чат по одному сообщению, то это получится будет 100 записей. Если хранить диалог, то это так и останется 10 строк в базе, что на порядок меньше. А если количество пользователей и их сообщений будет увеличиваться арифметически, то количество строк будет увеличиваться геометрически. Поэтому и пришли к тупику как хранить миллиарды сообщений. Завтра им придется хранить 10 или 100 миллиардов сообщений и они опять придут к тупику как жить дальше.
Есть ограничения на размер ячейки.
Если хранить чат в JSON строке, то для выборки и обработки нужно json полностью считывать или переписывать.
и какие ограничения? 1 гигабайт? Как у текстового поля? json тип и есть текстовое поле, только с валидацией.
записать пару мегабайт текста проще чем обновить таблицу с миллиардами записей из-за перестроения индексов. Да и я уже ниже написал, что чат размером в 2 мегабайта — это предел мечтаний.
кстати вот статья про постгрес и бенчмарки работы с JSON https://hashrocket.com/blog/posts/faster-json-generation-with-postgresql
записать пару мегабайт текста проще чем обновить таблицу с миллиардами записей из-за перестроения индексов. Да и я уже ниже написал, что чат размером в 2 мегабайта — это предел мечтаний.
кстати вот статья про постгрес и бенчмарки работы с JSON https://hashrocket.com/blog/posts/faster-json-generation-with-postgresql
Какие миллиарды записей, скорее миллион? В разделе хранятся данные из чата за 10 дней ≈ 100 МБ.
Сообщения удаляются не так часто чтобы перестроение индексов было критичным.
Вы какую СУБД предлагаете использовать?
Какие миллиарды записей, скорее миллион? В разделе хранятся данные из чата за 10 дней ≈ 100 МБ.а заголовок о чем говорит? Говорит о том что успешные пацаны научились без тормозов хранить 1кк записей. У меня сразу вопрос: а что будет если их будет 10кк или 100кк. Опять будут думать как хранить данные?
Сообщения удаляются не так часто чтобы перестроение индексов было критичным.индексы перестраиваются при UPDATE, DELETE, INSERT.
Вы какую СУБД предлагаете использовать?я не предлагаю какую-либо БД конкретно, я взываю к логике: хранить не отдельные реплики, а хранить диалоги в одном месте. Как уже приводил пример с диктофоном ниже.
2МБ это за какое время чат. У них чат за 10 дней весит 50-90 МБ.
Я считаю, что в Cassandra при одинаковом кол-ве сообщений добавление строки в таблицу сообщений это быстрее, чем считывание json строки из ячейки базы данных, добавление объекта сообщения и обратная запись в базу данных.
Можете так дальше считать.
Но предлагаю задуматься и ответить что быстрее:
1. найти нужную запись из миллиарда обновить ее и перестроить индекс?
2. найти нужную запись из сотен тысяч, обновить текст и сохранить его обратно не трогая индексы?
Но предлагаю задуматься и ответить что быстрее:
1. найти нужную запись из миллиарда обновить ее и перестроить индекс?
2. найти нужную запись из сотен тысяч, обновить текст и сохранить его обратно не трогая индексы?
Поле message_id все время увеличивается, так что индексы перестаиваться будут быстро.
В первом случае нет необходимости хранить миллиард сообщений в одном разделе Cassandra, можно хранить сотни тысяч сообщений.
так что индексы перестаиваться будут быстро.
а при чем тут быстро или не быстро обновляется индекс? Вопрос что из двух вариантов быстрее и жрет меньше процессорного времени?
Даже если вы сподобитесь провести бенчмарки на таблице с 10 записями, вы убедитесь, что апдейтнуть поле в 4 раза быстрее, чем просто вставить новую строку.
можно хранить сотни тысяч сообщений
вот к этому и приходят, когда нет нормальной архитектуры, начинают партиционировать таблицы или еще хуже, оправдывать переход с одной БД на другую и обратно левыми отмазками. Типичный пример с UBER.
Это не просто обновление поля, а
считывание json строки из ячейки базы данных, добавление объекта сообщения и обратная запись в базу данных.
Пока это будет выполняется, может начать добавляться уже следующий комментарий и привести к потере данных.
вот к этому и приходят, когда нет нормальной архитектуры, начинают партиционировать таблицы
Вообще-то это называется распределенная архитектура. Не хватает ресурсов и мощностей одного сервера для работы с единой базой данных.
При этом вы должны понимать, что не надо весь текст вытаскивать из ячейки, чтобы его обновить, достаточно туда просто добавить текст, а ля update table set text = text + new_text.
Вот у вас есть на телефон диктофон. Вы записываете разговор 10-рых людей. Вы же не пишете слова или реплики каждого человека в отдельный файл. Вы записываете всех и сразу, в единую запись. Чем чат отличается от диалога на диктофон? Да по сути ничем. Вы собираетесь менять слова говорящих, их интонацию, последовательность разговора? Нет конечно. Так и с чатом. Все что было сказано — это единое целое и зачем это разбивать на отдельный записи каждой реплики, если там ничего не изменится? Ни автор, ни дата, ни последовательность? Так хранить это как единый диалог всех участников.
Вы собираетесь менять слова говорящих, их интонацию, последовательность разговора?
Конечно собираемся. Именно для этого есть возможности редактировать и удалять сообщения. А также перемещаться к конкретным репликам. Мне кажется, диктофонная запись в данном случае — не самая подходящая аналогия, увы:)
А нельзя позволять редактирование и удаление. Всё введённое должно храниться для спецслужб. Удаление и редактирование – это слишком дорогие по IO и особенно по seek операции, и они редко выполняются пользователями. Ведите рядом ещё один файл, в который пишите своеобразный diff от основного. И ещё один индексный файл. Перемещаться по репликам можно на клиенте.
И если они бы продолжили осваивать Монгу, то рано или поздно пришли бы к подобной схеме денормализации (с массивом сообщений в одном документе). ИМХО, очередной пример того, как архитектурные недоработки проекта оправдываются страхами о неподконтрольности платформы и необходимостью замены её на что-то успокаивающе знакомое.
Они же написали, что не доверяют шардингу в MongoDB. Структура была такая же.
Вот структуру и нужно было менять.
Я хотел сказать обратное, хранить данные в массиве внутри объекта в MongoDB плохо, потому что существует ограничение на размер объекта в 16 МБ, ограничение же на размер коллекции – 4,2 млн документов и 32 терабайта.
Да, программировать не так просто, как может показаться, всюду куча ограничений. Так и живём.
Так вы теперь за или против массива сообщений в одном документе?
Конечно я за «несколькоуровневую» денормализацию данных в информационных системах, упирающихся в производительность при эксплуатации и масштабировании. Решать все свои проблемы только лишь выбором ПО (пафосно выписывая в столбик эпические требования своего грандиозного бизнеса к этому ПО) не получится, рано или поздно придётся проектировать и программировать.
потому что существует ограничение на размер объекта в 16 МБЭто совсем не причина. Не хватает одного документа — возьмите два, GridFS так и работает, хранит гигабайтные файлы в монге разбиавая на чанки. Считать 2 документа будет в сотни (тысячи) раз быстрее чем выкачать миллионы документов, не говоря об гигантской экономии памяти и диска.
Кроме того если сжать текст (xz/bzip) то в 16Мб можно уместить до 50-200Мб текста.
Разные подходы имеют свои преимущества (и недостатки), это глупо выбрасывать технологию из-за каких-то там ограничений (ограничения есть везде).
При чем тут MongoDB, когда разговор о Cassandra?
^^^^Ошибся веткой
выбрасывается не технология, а хранение архива объектов в документе. MongoDB в Discord не используют потому что нет уверенности в надежности шард.
ограничение же на размер коллекции – 4,2 млн
скорее 4.2 млрд, т. е. int32. У меня в коллекция малые сотни миллионов прекрасно живут без шардинга.
Нет в ней никаких ограничений на количество элементов, только на размер коллекции
a single MMAPv1 database has a maximum size of 32TB.
https://docs.mongodb.com/manual/reference/limits/#Database-Size
Да, конечно 4.2 млрд.
> при чем даже не надо на стороне сервера что-то парсить, пусть делает JS и рисует на основе данных интерфейс.
Выглядит достаточно сомнительно, если я правильно понял вашу идею. Даже пара мегабайт жисона очень хорошо подвешивают браузер при парсинге. А уж если это будет чат с миллионами сообщений… на клиент это выносить точно не стоит:)
Ну и как отметил товарищ выше, не совсем понятно, как резервировать такие данные и масштабировать такую систему.
Выглядит достаточно сомнительно, если я правильно понял вашу идею. Даже пара мегабайт жисона очень хорошо подвешивают браузер при парсинге. А уж если это будет чат с миллионами сообщений… на клиент это выносить точно не стоит:)
Ну и как отметил товарищ выше, не совсем понятно, как резервировать такие данные и масштабировать такую систему.
два мегабайта — это 2 097 000 байт. Длина одного символа UTF8 составляет от 1 до 6 байт. Возьмем среднее значение 3. То есть в 2 097 000 уместится 699000 тысяч символов. Средняя длина слова в английском языке составляет около 5 символов, соответственно это около 139800 слов. Средняя длина предложения в чате — 6 слов. То есть 23 300 предложений или сообщений в одном чате. Где вы видели чаты с таким количеством сообщений?
И потом никто не предлагает весь чат передавать на сторону клиента. Подгружать только последние 30-40 допустим, а если человек хочет прошлые посмотреть, загружай нужный период через AJAX и отдавай пользователю кусками.
И потом никто не предлагает весь чат передавать на сторону клиента. Подгружать только последние 30-40 допустим, а если человек хочет прошлые посмотреть, загружай нужный период через AJAX и отдавай пользователю кусками.
В статье же написано
Тяжёлые серверы приватных текстовых чатов Discord отправляют приличное количество сообщений, легко попадая в диапазон между 100 тыс. и 1 млн сообщений в год.
так это сумма всех приватных сообщений, а не в одном чате.
«Приватных» в данном случае, как я понял, противопоставлено публичным, т.е. общедоступным чатам. Т.е. под приватными чатами подразумеваются закрытые групповые чаты, а не чья-либо личка. Особенно если учесть фразу:
Но, т.к. дополнительных пояснений нет, то трактоваться может двояко, да
Виновником был публичный Discord-сервер подреддита Puzzles & Dragons. Поскольку он публичный, мы присоединились посмотреть.
Но, т.к. дополнительных пояснений нет, то трактоваться может двояко, да
Ну и как не очень активный, но всё же пользователь дискорда, могу сказать, что в групповых чатах там бывают ого-го какие бурные обсуждения и 23к сообщений не выглядят чем-то очень уж удивительным.
да даже если пользователю через websocket или AJAX отгрузить 2 мегабайта данных, то на стороне JS можно также делать выборку из цикла. На крайний случай разбить на несколько массивов, например помесячно или недельно. Так работают Whatsapp и Skype. Они отдают кусками, при подгрузке.
>>так что пользователи могут вернуться в любой момент и получить доступ к своим данным с любого устройства.
Разве что клавишей PgUp? Никаких других средств для этого в дискорде я не нашел. Ни перехода к дате, ни поиска по истории… По факту в высоконагруженных чатах указанным функционалом пользователь воспользоваться не может.
Разве что клавишей PgUp? Никаких других средств для этого в дискорде я не нашел. Ни перехода к дате, ни поиска по истории… По факту в высоконагруженных чатах указанным функционалом пользователь воспользоваться не может.
Sign up to leave a comment.
Как Discord хранит миллиарды сообщений