Comments 18
Вывод: выбор схемы шардинга сильно зависит от характера работы приложения с базой.
Вопрос 1.
Как быть с JOIN-ами?
Размещать связанные данные вместе?
У меня такое ощущение, что большие проекты не особо их используют, так как функционал у соцсетей слишком обрезанный.
Вопрос 2.
Вот я могу видеть список «избранного» / ленту в соцсети. При этом само избранное хранится с большой вероятностью на нескольких серверах.
Выполняется несколько запросов?
Вопрос 1.
Как быть с JOIN-ами?
Размещать связанные данные вместе?
У меня такое ощущение, что большие проекты не особо их используют, так как функционал у соцсетей слишком обрезанный.
Вопрос 2.
Вот я могу видеть список «избранного» / ленту в соцсети. При этом само избранное хранится с большой вероятностью на нескольких серверах.
Выполняется несколько запросов?
1. Если шардинг идет по пользователю, то можно делать джойны, поскольку все данные пользователя хранятся на одном шарде. Это супер-удобно, хотя будет плохо работать, если есть очень «большие» или «горячие» пользователи.
2. ID могут храниться на одном и том же сервере, а вот сами события в ленте могут храниться двумя способами, и один другой не исключает:
а) Распределенное хранилище, как у Facebook с шардингом по ID
б) Хранятся копии содержимого, как в Twitter
2. ID могут храниться на одном и том же сервере, а вот сами события в ленте могут храниться двумя способами, и один другой не исключает:
а) Распределенное хранилище, как у Facebook с шардингом по ID
б) Хранятся копии содержимого, как в Twitter
При всем моем глубоком уважении к докладчикам, доклад мне кажется слабоватым. Возможно, он просто ориентирован на начинающих.
мне последнее время кажется, что основная часть материала всех этих конференций уже пережёвывалась десятилетия назад. никакого нового слова в науке и технике не наблюдается.
а для начинающих конференцию незачем начинать — для черпания азов не нужен формат конференций, они больше для инноваций.
а для начинающих конференцию незачем начинать — для черпания азов не нужен формат конференций, они больше для инноваций.
Если говорить о конкретном докладе и конкретных докладчиках, то я был примерно в 2011 году на этом же самом докладе с этими же самыми докладчиками. На ютубе это появилось ещё раньше.
Так-то я не то что бы против :) Просто хотелось бы чего-нибудь действительно новенького и с большим уклоном в конкретную реализацию. Даже суть доклада можно оставить ту же, только один раз рассказывать про шардинг с Consul'ом, другой — с Eurek'ой, а потом вообще какое-то кастомное решение. Вот тогда было бы интересно.
Так-то я не то что бы против :) Просто хотелось бы чего-нибудь действительно новенького и с большим уклоном в конкретную реализацию. Даже суть доклада можно оставить ту же, только один раз рассказывать про шардинг с Consul'ом, другой — с Eurek'ой, а потом вообще какое-то кастомное решение. Вот тогда было бы интересно.
Круто! Только Вы были в 2014 году на этом докладе, потому что читали его в 2014-м.
Вот здесь разве не об этом же речь шла?
Несколько лет уже прошло, я точно не помню. Но то что уже несколько раз видел все основные тезисы Рыбака из этого доклада — это точно.
И да, в 2014 занимался другим направлением и точно не читал.
Несколько лет уже прошло, я точно не помню. Но то что уже несколько раз видел все основные тезисы Рыбака из этого доклада — это точно.
И да, в 2014 занимался другим направлением и точно не читал.
А что именно показалось слабоваты — показались простыми темы, или что-то освещено неверно/неполно?
Это keynote, и он всегда ориентирован на максимально широкую аудиторию. Что касается глубины: когда я начинал что-то рассказывать, это было лет десять назад, было очень много проектов, которые переходили из состояния «пара серверов» в состояние «много серверов»; люди вообще боялись что-то рассказывать (из некоторых компаний — до сих пор боятся), поэтому очень многое было в новинку. Теперь это в большей степени рутина, проектов уже не единицы, больших проектов только на нашем рынке уже сотни (или тысячи), информации полно, может быть, поэтому основы кажутся банальными и хочется чего-то более интересного? На этом юбилейном Хайлоаде будет доклад про использование MySQL в Badoo — там уже будет практика шардинга. Ну или приходите в нашу фейсбук-группу, обсудим что-нибудь небанальное https://www.facebook.com/groups/feedme.ru/
Это keynote, и он всегда ориентирован на максимально широкую аудиторию. Что касается глубины: когда я начинал что-то рассказывать, это было лет десять назад, было очень много проектов, которые переходили из состояния «пара серверов» в состояние «много серверов»; люди вообще боялись что-то рассказывать (из некоторых компаний — до сих пор боятся), поэтому очень многое было в новинку. Теперь это в большей степени рутина, проектов уже не единицы, больших проектов только на нашем рынке уже сотни (или тысячи), информации полно, может быть, поэтому основы кажутся банальными и хочется чего-то более интересного? На этом юбилейном Хайлоаде будет доклад про использование MySQL в Badoo — там уже будет практика шардинга. Ну или приходите в нашу фейсбук-группу, обсудим что-нибудь небанальное https://www.facebook.com/groups/feedme.ru/
Дисклеймер — написанное ниже очень субъективно и скорее всего придирки. И я понимаю, что целью доклада не являлось осветить это все. Тем не менее.
Во-первых, существует некоторая путаница с терминологией. Каждая СУБД использует немного свои термины, но наиболее общий знаменатель примерно следующий. Под решардингом обычно понимают изменение числа бакетов/vnode. Например, если было hash(key) % 512, решили, что бакетов маловато, и перешли на hash(key) % 1024 или вообще на другую схему. Перенесение бакетов на другие физические машины обычно называют перебалансировкой. Как минимум, было бы не лишним предупредить, что такая путаница вообще есть. Вы же, как я понял, просто для всего решили использовать слово решардинг, тем самым, как мне кажется, оказывая слушателям медвежью услугу.
Во-вторых, немного удивили повороты в стиле что прокси — это SPOF или что во время перебалансировки нода может упасть. Мне кажется само собой разумеющимся, что прокси должен быть не в одном экземпляре, и что «нода» это на самом деле мастер и пара реплик с фейловером (ручным или автоматическим).
Наконец, да, полнота доклада. Что на самом деле интересно слушателям? Как им взять какой-нибудь Redis/Tarantool/PostgreSQL/MySQL/иную-систему-без-встроееного-шардинга и на базе нее построить что-то что масштабируется гаризонтально. Что для этого нужно? Да, действительно, какая-то схема шардирования, какой-то сервис дисковери (как получилось, что не вспомнили хотя бы ZooKeeper, не говоря уже про Consul или etcd? снова оказание медвежьей услуги — ведь слушатели побегут писать свое), процедура решардинга, процедура ребалансировки (важно подчеркнуть, что это отдельные вещи) и, самое интересное, транзакции между нодами.
В сухом остатке. Вы подняли интересную тему, но не дали ответа на вопрос, который действительно всех интересует. Изложение явно не полное. В связи с чем отчасти даже вредное, а не полезное.
Повторюсь, это все субъективная оценка. И я понимаю, что доклад, видимо, был ориентирован на новичков и делался, наверное, давно. Я постараюсь в ближайшем будущем написать свою версию того, как можно решить все описанные проблемы на примере PostgreSQL.
Во-первых, существует некоторая путаница с терминологией. Каждая СУБД использует немного свои термины, но наиболее общий знаменатель примерно следующий. Под решардингом обычно понимают изменение числа бакетов/vnode. Например, если было hash(key) % 512, решили, что бакетов маловато, и перешли на hash(key) % 1024 или вообще на другую схему. Перенесение бакетов на другие физические машины обычно называют перебалансировкой. Как минимум, было бы не лишним предупредить, что такая путаница вообще есть. Вы же, как я понял, просто для всего решили использовать слово решардинг, тем самым, как мне кажется, оказывая слушателям медвежью услугу.
Во-вторых, немного удивили повороты в стиле что прокси — это SPOF или что во время перебалансировки нода может упасть. Мне кажется само собой разумеющимся, что прокси должен быть не в одном экземпляре, и что «нода» это на самом деле мастер и пара реплик с фейловером (ручным или автоматическим).
Наконец, да, полнота доклада. Что на самом деле интересно слушателям? Как им взять какой-нибудь Redis/Tarantool/PostgreSQL/MySQL/иную-систему-без-встроееного-шардинга и на базе нее построить что-то что масштабируется гаризонтально. Что для этого нужно? Да, действительно, какая-то схема шардирования, какой-то сервис дисковери (как получилось, что не вспомнили хотя бы ZooKeeper, не говоря уже про Consul или etcd? снова оказание медвежьей услуги — ведь слушатели побегут писать свое), процедура решардинга, процедура ребалансировки (важно подчеркнуть, что это отдельные вещи) и, самое интересное, транзакции между нодами.
В сухом остатке. Вы подняли интересную тему, но не дали ответа на вопрос, который действительно всех интересует. Изложение явно не полное. В связи с чем отчасти даже вредное, а не полезное.
Повторюсь, это все субъективная оценка. И я понимаю, что доклад, видимо, был ориентирован на новичков и делался, наверное, давно. Я постараюсь в ближайшем будущем написать свою версию того, как можно решить все описанные проблемы на примере PostgreSQL.
Спасибо за Ваши комментарии. Отвечу по пунктам:
(1) Терминилогия. Если честно, я какого-то особенного дискомфорта не испытываю, и в общем-то первый раз слышу о том, чтобы увеличение числа бакетов как-то именовалось отдельно, а перераспределение данных по серверам — отдельно. хотя термины, которые вы предлагаете — мне они нравятся.
(2) Реализация узлов на практике. Что прокси, что координатор — spof, их нужно готовить именно хотя бы как m/s, и это здорово, что вам это очевидно. Поверьте, оно очевидно не всем. Но вот дальше уже неоднозначно. Если «пользовательская» нода — это мастер и пара реплик (т.н. replica set) то вы получаете утроение мощностей с куста, если грубо: лучше забить на redundancy/failover и 1/1000 кластера пусть может быть полежит, пока ребилдится RAID, чем иметь 3000 серверов в кластере.
(3) Как на базе чего-то «односерверного» и сделать «кластер». Это отличная тема, но я боюсь, что вы несколько переоцениваете как возможности уложить это в формат конференции (30 минут), так и способности аудитории за эти самые 30 минут это понять. У меня есть некоторый опыт подобного рассказа про MySQL — это несколько часов, причем без дискавери (дискавери — это maintenance нахлобучка, она сама по себе на архитектуру и понимание работы не влияет, а людям интересны чисто программерские темы — джойны, уникальность ключей, аналитика и тд). Что касается транзакций между нодами: так «сбоку» их прикрутить как раз и не получится, их можно только заменить асинхронно через внутренние очереди.
(1) Терминилогия. Если честно, я какого-то особенного дискомфорта не испытываю, и в общем-то первый раз слышу о том, чтобы увеличение числа бакетов как-то именовалось отдельно, а перераспределение данных по серверам — отдельно. хотя термины, которые вы предлагаете — мне они нравятся.
(2) Реализация узлов на практике. Что прокси, что координатор — spof, их нужно готовить именно хотя бы как m/s, и это здорово, что вам это очевидно. Поверьте, оно очевидно не всем. Но вот дальше уже неоднозначно. Если «пользовательская» нода — это мастер и пара реплик (т.н. replica set) то вы получаете утроение мощностей с куста, если грубо: лучше забить на redundancy/failover и 1/1000 кластера пусть может быть полежит, пока ребилдится RAID, чем иметь 3000 серверов в кластере.
(3) Как на базе чего-то «односерверного» и сделать «кластер». Это отличная тема, но я боюсь, что вы несколько переоцениваете как возможности уложить это в формат конференции (30 минут), так и способности аудитории за эти самые 30 минут это понять. У меня есть некоторый опыт подобного рассказа про MySQL — это несколько часов, причем без дискавери (дискавери — это maintenance нахлобучка, она сама по себе на архитектуру и понимание работы не влияет, а людям интересны чисто программерские темы — джойны, уникальность ключей, аналитика и тд). Что касается транзакций между нодами: так «сбоку» их прикрутить как раз и не получится, их можно только заменить асинхронно через внутренние очереди.
На счет терминов хочется подчернкнуть, что это не мое личное предложение. Это по мотивам терминологии, используемой в документации Couchbase, Cassandra, Riak, CockroachDB и других СУБД со встроенным шардингом/перебалансировкой.
По поводу прикручивания транзакций сбоку позвольте не согласиться. Прикручиваются, хоть и не без осведомленности приложения или middleware через который приложение ходит в базу http://rystsov.info/2012/09/01/cas.html По-моему там в статье это не подчеркнуто, но чтобы получить настоящий snapshot isolation нужно при чтении ключей делать с ними то же самое, что и при записи. В документации к некоторым СУБД это называют 2PC транзакциями, но мне этот термин не нравится, так как к настоящему 2PC отношения не имеет.
По поводу прикручивания транзакций сбоку позвольте не согласиться. Прикручиваются, хоть и не без осведомленности приложения или middleware через который приложение ходит в базу http://rystsov.info/2012/09/01/cas.html По-моему там в статье это не подчеркнуто, но чтобы получить настоящий snapshot isolation нужно при чтении ключей делать с ними то же самое, что и при записи. В документации к некоторым СУБД это называют 2PC транзакциями, но мне этот термин не нравится, так как к настоящему 2PC отношения не имеет.
Насчет статьи для PostgreSQL — очень интересно!
Обещанная статья: http://eax.me/sharding/
Я, как всегда, пытался убедить Алексея больше использовать Tarantool, а он сказал, что там до сих пор нет шардинга и, вообще, неинтересно. Тогда мы стали рассуждать о том, почему нет. Я стал рассказывать, что тут нет одного универсального решения, автоматика полная за вас работает, а вы только кофе на работе пьете и все…
Поэтому родился этот доклад — чтобы посмотреть на то, какой бывает шардинг, какие методы в каких системах используются, какие преимущества и недостатки, почему нельзя одной «серебряной пулей» все решить?
В докладе рассмотрено, что можно делить данные так, а можно эдак. Однако этот доклад не служит объяснением изначального посыла: почему нельзя иметь встроенные механизмы шардинга по различным ключам.
Кластерные базы данных имеют встроенные расширения для шардирования. Надо понимать, они это делают сугубо неэффективными методами?
Насколько я знаю, в тарантуле обещают добавить автошардинг, так что следите за новостями :).
почему нельзя всё решить — можно, только способов очень много, то есть понимать это нужно так, что ты должен предложить сразу несколько механизмов — и только тогда ты можешь претендовать на универсальность. для примера типичная проблема «автошардинга»: переезд данных одного шард-ключа между дц, например (потому что «формула», и по ней перевозить можно только «бакет»).
Константин Осипов: Еще пара слов о недостатках этой истории с хэшированием… у вас может так получиться, что сервер №3 находится рядом с сервером №1, а между серверами №2 и №3 такое большое полукольцо — практически половина данных.
На самом деле проблемы с распределением в consistent hashing нет, надо просто дать случайности поработать. Для этого каждому серверу дают не один а например 256 диапазонов. И два сервера 512 раз бросив кубик получат красивое деление 50/50. Добавляется третий сервер, ещё 256 случайностей распределят хэши ровно по трети. Более того, при этом новый сервер получит примерно по равной части от каждой ноды, а это значит, что нагрузка на перенос данных будет распределена по всему кластеру. См. cassandra virtual nodes.
Sign up to leave a comment.
Sharding – patterns and antipatterns