Думаю, хорошее решение - использовать виртуальные шарды. Вы можете начать с одного сервера и направить весь виртуальный сегмент на один сервер. Используйте модуль для инкрементного идентификатора, чтобы равномерно распределить строки по виртуальным осколкам. С Amazon RDS у вас есть возможность превратить ведомое устройство в ведущее, поэтому, прежде чем изменять конфигурацию сегментирования (указать больше виртуальных сегментов на новый сервер), вы должны сделать ведомое устройство ведущим, затем обновить файл конфигурации и затем удалить все записи на новом главном сервере с использованием модуля, не соответствующего диапазону сегментов, который вы используете для нового экземпляра.
Вам также необходимо удалить строки с исходного сервера, но к настоящему времени все новые данные с идентификаторами, которые модулируются на основе новых диапазонов виртуальных сегментов, будут указывать на новый сервер. Таким образом, вам на самом деле не нужно перемещать данные, но воспользуйтесь функцией продвижения сервера Amazon RDS.
Затем вы можете сделать реплику с исходного сервера. Вы создаете уникальный идентификатор как: идентификатор фрагмента + идентификатор типа таблицы + инкрементный номер. Поэтому, когда вы запрашиваете базу данных, вы знаете, в какой сегмент нужно перейти и получить данные.
Я не знаю, как это можно сделать с помощью RavenDB, но он может неплохо работать с Amazon RDS, потому что Amazon уже предоставляет вам функцию репликации и продвижения серверов.
Я согласен с тем, что это должно быть решение, которое с самого начала предлагало бы беспрепятственную коммуникацию и не говорило разработчику, что нужно решать проблемы, когда они возникают. Кроме того, я обнаружил, что многие решения NoSQL, которые равномерно распределяют данные по шардам, должны работать в кластере с низкой задержкой. Так что вы должны принять это во внимание. Я пробовал использовать Couchbase с двумя разными машинами EC2 (не в выделенном кластере Amazon), и балансировка данных была очень медленной. Это тоже увеличивает общую стоимость.
Я также хочу добавить, что компания pinterest решила свои проблемы с масштабируемостью, используя 4096 виртуальных шардов.
Вам также следует изучить проблемы разбиения на страницы во многих базах данных NoSQL. При таком подходе вы можете довольно легко разбивать данные на страницы, но, возможно, не самым эффективным способом, потому что вам может потребоваться запросить несколько баз данных. Другая проблема - изменение схемы. Pinterest решил эту проблему, поместив все данные в JSON Blob в MySQL. Если вы хотите добавить новый столбец, вы создаете новую таблицу с данными нового столбца + ключ и можете использовать индекс для этого столбца. Если вам нужно запросить данные, например, по электронной почте, вы можете создать другую таблицу с адресами электронной почты + ID и поместить индекс в столбец электронной почты. Другая проблема - счетчики, я имею в виду атомные счетчики. Так что лучше вынуть эти счетчики из JSON и поместить их в столбец, чтобы вы могли увеличивать значение счетчика.
Есть отличные решения, но в конце концов вы обнаруживаете, что они могут быть очень дорогими. Я предпочел потратить время на создание собственного решения для шардинга, чтобы потом не заболеть. Если вы выберете другой путь, множество компаний ждут, когда у вас возникнут проблемы, и попросят немалые деньги для решения ваших проблем. Потому что в тот момент, когда они вам понадобятся, они знают, что вы заплатите все, чтобы ваш проект снова заработал. Это из моего собственного опыта, поэтому я ломаю себе голову, чтобы создать собственное решение для сегментирования, используя ваш подход, который также будет намного дешевле.
Другой вариант - использовать промежуточное программное обеспечение для MySQL, например ScaleBase или DBshards. Таким образом, вы можете продолжить работу с MySQL, но в то время, когда вам нужно масштабировать, у них есть хорошо зарекомендовавшее себя решение. И затраты могут быть намного ниже, чем у альтернативы.
Еще один совет: когда вы создаете свою конфигурацию для шардов, поместите атрибут write_lock, который принимает false или true. Таким образом, если установлено значение false, данные не будут записаны в этот сегмент, поэтому, когда вы получите список сегментов для определенного типа таблицы (то есть пользователей), он будет записан только в другие сегменты для того же типа. Это также хорошо для резервного копирования, так что вы можете показать дружественную ошибку для посетителей, когда вы хотите заблокировать весь сегмент при резервном копировании всех данных, чтобы получить моментальные снимки всех сегментов. Хотя я думаю, что вы можете отправить глобальный запрос на создание снимков всех баз данных с помощью Amazon RDS и использования резервного копирования на определенный момент времени.
Дело в том, что большинство компаний не будут тратить время на работу с самостоятельным решением для сегментирования, они предпочтут платить за ScaleBase. Это решение исходит от отдельных разработчиков, которые могут позволить себе платить за масштабируемое решение с самого начала, но хотят быть уверены, что когда они дойдут до нужной точки, у них будет решение. Просто посмотрите на цены там, и вы поймете, что это будет вам дорого стоить. Я с радостью поделюсь с вами своим кодом, когда закончу. На мой взгляд, вы идете лучшим путем, все зависит от логики вашего приложения. Я моделирую свою базу данных так, чтобы она была простой, без соединений, без сложных запросов агрегирования - это решает многие из моих проблем. В будущем вы можете использовать Map Reduce для решения этих задач, связанных с большими данными.
person
Idan Shechter
schedule
04.11.2012
