Упорядочить по нескольким базам данных в шардинге

Question

Предположим, что мы разрабатываем Instagram с миллиардами пользователей. Мы разделяем таблицы фотографий в нескольких базах данных (в разных экземплярах / серверах / устройствах разделения), а в таблицах фотографий имеется столбец createdAt. Теперь пользователь открывает домашнюю вкладку в приложении, приложение должно показать последние 20 фотографий (order by createdAt desc) глобально (не локально) по таблицам фотографий в нескольких базах данных. Каким должен быть запрос SQL?

Мы должны разделить таблицу фотографий, потому что миллиарды пользователей будут делать сотни миллиардов фотографий. Мы не можем хранить и обслуживать сотни миллиардов фотографий в одной таблице в одной базе данных на одном сервере.

Скажем, у нас есть 100 серверов баз данных, одним из возможных решений является запрос select id from photo order by createdAt desc limit 20 к таблицам фотографий более 100 баз данных. сервера. Затем в нашем бэкэнде мы получаем 20 * 100 = 2000 строк фотографий и сортируем их по созданному в бэкэнде (Node.js, Java, Python, et c) и возвращаем только первые 20 строк.

Answer 1

Пока рано говорить о шардинге. Не думайте об этом, пока в вашем наборе данных не появятся миллионы записей.

К тому времени вы будете изменять схему по крайней мере один раз. Только после, скажем, второго или третьего редизайна следует беспокоиться о шардинге. Например ...

Когда вы попадете туда, вот несколько советов:

• Одна таблица (или небольшая группа тесно связанных таблиц) будет разделить на несколько машин («sharding»).
• Другие таблицы должны быть либо дублированы по частям, либо храниться на отдельных машинах. Ведение этих таблиц становится отдельной задачей администратора.
• Это будет закрыто каким-то "id". Ваш выбор идентификатора может измениться; но пока не зацикливайтесь на этом. UUID имеют проблемы с производительностью, но позволяют нескольким клиентам независимо создавать уникальные идентификаторы. Есть лучшие способы; перезвоните позже.
• Вам понадобятся несколько уровней компьютеров - для баз данных, веб-серверов, маршрутизаторов и т. д. c.
• Запрос, который должен проверять все фрагменты, будет сложным. писать и медленно для запуска. Поэтому старайтесь избегать такого.
• Разделение может быть выполнено путем хеширования или словаря или их комбинации.
• Напишите инструмент для переноса пользователя из одного сегмента в другой. Этот инструмент является ключом к упрощению ряда задач - обновлений оборудования, обновлений программного обеспечения, восстановления cra sh, балансировки нагрузки и т. Д. c, et c.
• размещения фотографий на отдельных серверах; хранить только URL-адреса в базе данных. Это упрощает работу, повышает эффективность использования аппаратного обеспечения и т. Д. c.
• 100B фотографий по 1 МБ каждая - для этого потребуется много стандартных машин или несколько огромных сетей SAN. Сохранение этого независимого от базы данных позволяет вам масштабировать его отдельно.
• «20 самых последних фотографий во всех шардах». Предлагаем вам использовать незащищенный сервер с API, основная цель которого - получать URL-адреса и поддерживать их. список; плюс доставить список. Это может быть все, что может обработать один сервер. А попадание во все осколки все время, вероятно, поставит всю систему на колени.
• Вам понадобятся сотни серверов для того, что вы описываете; каков твой бюджет? И каково ваше требование HA? Сотни машин == один сбой каждые несколько дней. И вам нужно будет добавлять другой сервер каждые несколько дней только для увеличения емкости. Сколько SA / DBA ИТ-специалистов вы будете нанимать?

Flickr был построен лет go на защищенных MySQL серверах. Так что можно. У них была одна «группа», единственной целью которой было загрузить миллион фотографий. этот «кит» дал им некоторые проблемы.

Answer 2

Похоже, что вы ищете, это Spider Storage Engine от MariaDB . Это позволит вам иметь каждый раздел на другом сервере. Вы должны знать, что подобные архитектуры никогда не бывают полностью прозрачными - чтобы получить максимальную (или даже хорошую) производительность, вам придется спроектировать все ваше приложение с учетом побочных эффектов производительности основного хранилища данных.

Answer 3

Если разделение сервера базы данных по пользователям является логической картой для этой таблицы, примените отображение в приложении (предпочтительно отображение, которое не требует поиска в базе данных), а затем просто непосредственно этот сервер базы данных с SELECT .. FROM photos ORDER BY createdAt DESC