LINUX.ORG.RU

История изменений

Исправление lesopilorama, (текущая версия) :

  1. Транзакции. Знаем такое слово. Но фича ради фичи не интересна, а высказывание «в отсутствии транзакций работать НОРМАЛЬНО ничего не может» ложно. Хорошо, что понятие нормальности у всех своё, бугага.

  2. Тред не про аттачи.

  3. Обычный подход в хайлоаде. Тяжело что-то джойнить без сетевого трафика на размазанной по трём дата-центрам базе.

  4. Девопсы не нужны, всё стандартизовано и выглядит одинаково, разные конфиги просто. Бинарник нашей базы везде один и тот же. systemd сам всё запустит без девопса ссаного. Любая из вышеперечисленых баз внутри одинакова. Падают одинаково, чинятся одинаково, поставляются одинаково. И хватит называть админов девопсами, что за смузихлёбство.

  5. Лайки шардируются по (chat_id) например. Все лайки всех сообщений одного чата лежат на каком-то одном сервере. Не приходится ходить по всем дата-центрам. Не помню как точно выглядит это, но достать все лайки или их отсутствие на ряд извлечённых из MESSAGE сообщенек - это один запрос.

  6. Объект - это буквально как строка/тупл в PostgreSQL (или как JSON в MongoDB, но не JSON и не в MongoDB и если бы последовательность полей в JSON была фиксирована). Последовательность мессаг в чатике - тупо последовательность этих «документов» или «строк». В документе лежит штук 10-15 полей про эту мессагу. Про лайкании мессаги, если раньше на ней никаких реакций не стояло, мы этой месаге меняем одно поле без полной перезаписи объекта. А если были реакции, то ничего не меняем. Просто далее в базе LIKES уточняем чо какие реакции понаставлены. У «Message» есть только флаг «реакции какие-то есть». Если флаг тру, то пойти в LIKES для уточнения и достать оттуда.

На красоту архитектуры нам глубоко насрать, у нас цель микросекунды лутать. Если выглядит как говно, но едет быстро - мы за это душу отдаём. При этом конечно, возможны просёры данных, но мы их локализуем в «необязательных областях». Например лайк просрать можем себе позволить, а мессагу не можем. Ради полной суперсогласованности платить чем-то не готовы никогда, сорян, таковы законы микросекунд и большого бизнеса! Щепки рубят бабки летят! Такие дела.

Исправление lesopilorama, :

  1. У нас есть транзакции! У нас есть AI! Наши сервера освящены батюшкой. Не, нам надо чтобы работало, а не фича ради фичи. Высказывание «в отсутствии транзакций работать ничего не может» ложно.

  2. Вроде не озвучивалась такая проблема, её вроде бы нет. С аттачами у нас вообще весело, но это ещё срачь на сто страниц, не будем начинать.

  3. Обычный подход в хайлоаде. Что ты там джойнить без сетевого трафика собрался на размазанной по трём дата-центрам базе…

  4. Девопсы нахрен не нужны, всё стандартизовано и выглядит одинаково, разные конфиги просто. Бинарник нашей базы везде один и тот же. systemd сам всё запустит без девопса ссаного.

  5. Лайки шардируются по (chat_id) например. Все лайки всех сообщений одного чата лежат на том же сервере, где лежит этот чатик. Не приходится ходить по всем дата-центрам. Не помню как точно выглядит это, но навешать лайки на достанные из базы только что сообщения - это один запрос.

  6. Объект - это буквально как строка/тупл в PostgreSQL (или как JSON в MongoDB, но не JSON и не в MongoDB и если бы последовательность полей в JSON была фиксирована). Последовательность мессаг в чатике - тупо последовательность этих «документов» или «строк». В документе лежит штук 10-15 полей про эту мессагу. Про лайкании мессаги, если раньше на ней никаких реакций не стояло, мы этой месаге меняем одно поле без полной перезаписи объекта. А если были реакции, то ничего не меняем. Просто далее в базе LIKES уточняем чо какие реакции понаставлены. У «Message» есть только флаг «реакции какие-то есть». Если флаг тру, то пойти в LIKES для уточнения и достать оттуда.

На красоту архитектуры нам глубоко насрать, у нас цель микросекунды лутать. Если выглядит как говно, но едет быстро - мы за это душу отдаём. При этом конечно, возможны просёры данных, но мы их локализуем в «необязательных областях». Например лайк просрать можем себе позволить, а мессагу не можем. Ради полной суперсогласованности платить чем-то не готовы никогда, сорян, таковы законы микросекунд и большого бизнеса! Щепки рубят бабки летят! Такие дела.

Исправление lesopilorama, :

  1. У нас есть транзакции! У нас есть AI! Наши сервера освящены батюшкой. Не, нам надо чтобы работало, а не фича ради фичи. Высказывание «в отсутствии транзакций работать ничего не может» ложно.

  2. Вроде не озвучивалась такая проблема, её вроде бы нет.

  3. Обычный подход в хайлоаде. Что ты там джойнить без сетевого трафика собрался на размазанной по трём дата-центрам базе…

  4. Девопсы нахрен не нужны, всё стандартизовано и выглядит одинаково, разные конфиги просто. Бинарник нашей базы везде один и тот же. systemd сам всё запустит без девопса ссаного.

  5. Лайки шардируются по (chat_id) например. Все лайки всех сообщений одного чата лежат на том же сервере, где лежит этот чатик. Не приходится ходить по всем дата-центрам. Не помню как точно выглядит это, но навешать лайки на достанные из базы только что сообщения - это один запрос.

  6. Объект - это буквально как строка/тупл в PostgreSQL (или как JSON в MongoDB, но не JSON и не в MongoDB и если бы последовательность полей в JSON была фиксирована). Последовательность мессаг в чатике - тупо последовательность этих «документов» или «строк». В документе лежит штук 10-15 полей про эту мессагу. Про лайкании мессаги, если раньше на ней никаких реакций не стояло, мы этой месаге меняем одно поле без полной перезаписи объекта. А если были реакции, то ничего не меняем. Просто далее в базе LIKES уточняем чо какие реакции понаставлены. У «Message» есть только флаг «реакции какие-то есть». Если флаг тру, то пойти в LIKES для уточнения и достать оттуда.

На красоту архитектуры нам глубоко насрать, у нас цель микросекунды лутать. Если выглядит как говно, но едет быстро - мы за это душу отдаём. При этом конечно, возможны просёры данных, но мы их локализуем в «необязательных областях». Например лайк просрать можем себе позволить, а мессагу не можем. Ради полной суперсогласованности платить чем-то не готовы никогда, сорян, таковы законы микросекунд и большого бизнеса! Щепки рубят бабки летят! Такие дела.

Исходная версия lesopilorama, :

  1. У нас есть транзакции! У нас есть AI! Наши сервера освящены батюшкой. Не, нам надо чтобы работало, а не фича ради фичи. Высказывание «в отсутствии транзакций работать ничего не может» ложно.

  2. Вроде не озвучивалась такая проблема, её вроде бы нет.

  3. Обычный подход в хайлоаде. Что ты там джойнить без сетевого трафика собрался на размазанной по трём дата-центрам базе…

  4. Девопсы нахрен не нужны, всё стандартизовано и выглядит одинаково, разные конфиги просто. Бинарник нашей базы везде один и тот же. systemd сам всё запустит без девопса ссаного.

  5. Лайки шардируются по (chat_id) например. Все лайки всех сообщений одного чата лежат на том же сервере, где лежит этот чатик. Не приходится ходить по всем дата-центрам. Не помню как точно выглядит это, но навешать лайки на достанные из базы только что сообщения - это один запрос.

  6. Объект - это буквально как строка/тупл в PostgreSQL (или как JSON в MongoDB, но не JSON и не в MongoDB и если бы последовательность полей в JSON была фиксирована). Последовательность мессаг в чатике - тупо последовательность этих «документов» или «строк». В документе лежит штук 10-15 полей про эту мессагу. Про лайкании мессаги, если раньше на ней никаких реакций не стояло, мы этой месаге меняем одно поле без полной перезаписи объекта. А если были реакции, то ничего не меняем. Просто далее в базе LIKES уточняем чо какие реакции понаставлены. У «Message» есть только флаг «реакции какие-то есть». Если флаг тру, то пойти в LIKES для уточнения и достать оттуда.

На красоту архитектуры нам глубоко насрать, у нас цель микросекунды лутать. Если выглядит как говно, но едет быстро - мы за это душу отдаём. При этом конечно, возможны просёры данных, но мы их локализуем в «необязательных областях». Например лайк просрать можем себе позволить, а мессагу не можем. Такие дела.