13 520
правок
Изменения
Нет описания правки
== Хранилище почты mail.ru ==
'''Виктор Могилин (mail.ru) - — Хранилище для Почты''' Доклад сделал мой день, самый интересный доклад первого дня. Ну, для меня. Очень уж хранилки всякие люблю. Итак. Сначала почта у них хранилась, видимо, в Maildir-ах, ну или в своём аналоге, то есть ящик - это была папочка на диске, в которой отдельными файлами хранились все письма, плюс индексы. В среднем примерно 3 ТБ вложений на 1 ТБ писем. Горизонтально это масштабировалось норм, а вертикально не норм - предел - 4 ТБ HDD, больше юзать не получалось, т.к. iops-ы HDD с объёмом не растут (100-200 iops). ФС - очевидный оверхед: директории, иноды... Так и масштабировались на 4 ТБ дисках, в итоге домасштабировались до 3000 серверов и стало дорого и неудобно. Захотелось снизить это число раз в 10. Для начала дизагрегировали вложения, по этому поводу был отдельный доклад: [https://www.youtube.com/watch?v=O247Hq3ego4 Как смигрировать 50Пб в 32 без даунтайма? / Альберт Галимов, Андрей Сумин (Mail.ru)] с хайлоада 2016. Соотношения объёмов данных и нагрузки: мета — 2 ПБ и 3 млн rps, тексты писем — 15 ПБ и 80 тысяч rps, вложения — <s>50</s> 35 ПБ и 8 тысяч rps. В итоге в этом докладе речь идёт только о хранилище сообщений. - zepto- bucket-видимо pg. ан нет, это еблоб реплицированный. волюм seaweedfs. правда странички по 4 кб. есть crc на 4 кб. фоновые скрабы. нахуя 4кб.. если хедеры мелкие- версия бакета = оффсет в файле. о, дельты, привет!- zeptoproxy клиент прямо рядом с приложением- 1 диск = 1 bucketservice. разные порты. осд короче. фоновые - bucketcompactor- statusservice. индекс бакетов. дельтами получает. держит карту бакетов в памяти. api: дай бакет для записи, дай адрес по бакету. пошардирован по дц. мастер для своих бакетов %3- размер бакета 2 ТБ. пиздец же, мало. а они довольны, типа меньше чем было- fallocate. врайты в конец. мало меты. мало лишних иопс- кворумная запись. пись. пись- x2, x3, x1.5- xor. полторирование. ебать хитрая сосиска. после закрытия. ну видимо конвертация сосиски после. а шо с удалением из ec?- схема добавления дисков в кластер. жесткая. это как? а, видимо разделения места. я так умею на lpsolve, лолъ- пары это logical partitions- ретраи на пут, на гет. все ясно. а если данные убрали из памяти, стрим?- zeptoid=bid+recordid, 64bit. 2^64 байт? = 16 ЕБ. смещение что ли? почта = 15 пет, им похуй. ебааааать, индекс удалений. ну да, забавно сделано- delete = put в конец. lock. compact. по % удалений как и везде. а EC?- консистентность делете: ну это томбстоуны, понятно... а, не совсем. есть foreign del, форвард другому бакету- zeptoctl. move in = новая группа. тоже приоритет пустых. потом будет перекос по get-ам. есть масштабирование. средний du. не, стоп, а нагрузка?- ждем ебилдов.- 18Т диски, 12Т вложения, 6Т письма, 20-40 иопс на диск. вложения отдельно, не зепто. 60 дисков на сата-полке. сата?- zstd. 15т -> 30т -> 15т- серверов 3к -> 1.5к. индексы в 250- облако 80 пб, х1.5. сниппеты поиска 2.4п.- гибридная схема тоже хотят.- удаления накур. лишнее ио.- ручной move in, fix. боязнь админов, ага.- как смигрировать 50пб в 32- синк по смещениям?- Вадим ты чота завернул блеа. 6 дисков 15 пар- процессы порты. ец удаление. нагрузка. сата полка. синк по смещениям?- запись под локом. статус сервис лочит. епт. 72д по 6т.- цеф им нинужен. как удаления из ец хз лол, он не ответил- большие файлы чанкуются по 64 мб.- zeptoId какой-то еще последней записи. емое... в которой все. ааа. понятно. она с чанками
== SPQR для постгри ==
