Доброго времени суток!

Поделитесь идеями по сабжу плиз.

Постановка задачи:

Есть таблица, содержащая данные для закладочного сервиса.
Таблица содержит древесные структуры в виде "Cписок соседства" (то есть каждая строка содержит ссылку parent_id на отцовский элемент, находящийся в этой же таблице, у корней parent_id равен null). Глубина дерева - максимум пять элементов, среднее дерево содержит не больше 50 элементов.

В архитектуру базы нужно заложить возможность горизонтального шардинга (эта таблица самая большая в системе), то есть разбить эту таблицу на несколько БД-серверов.

То есть если одного сервера начинает не хватать, чтобы можно было поставить еще один. Если потребуется - еще один. и. т. д.

И вот тут возникают вопросы.

1) По какому критерию можно было бы лучше всего организовать разбиение по шардам?
Сами элементы закладочного сервиса ссылаются на пользователя, который владелец закладки,
иногда содержат в себе ссылки, имеют название и описание, имеют время создания/модификации. Единственное хорошее, что приходит в голову - шардировать по времени.

2) Как добиться уникальности ключа в условиях распределенной БД?
Рассматриваю пока следующие варианты:

1) Решение в виде разбить диапазон значений на поддиапазоны и назначить каждый шард отвечать за свой диапазон (допустим по миллиону или по 10 миллионов на каждый шард). То есть в этом случае шард определяется просто порядковым номером ID.

2) Решение от Instagram .
Выглядит очень изящно, но непонятно - в какой шард, допустим, вставлять следующее дерево сервиса.

Как-то так. У кого есть идеи или наработки грамотной реализации - поделитесь плиз.

deadka, если делать все "грамотно" по инстраграму - можно вообще никогда не доделать.
Обратите внимание на такие переменные mysql как auto-increment-increment и auto-increment-offset.

netwind, а что, собственно, такого нереального в инстаграмовской задумке хранения распределенного id?
Спасибо за наводку на auto_increment_..., но смущает то, что не нашёл возможности задать эти параметры для одной таблицы. Устанавливать же их для всего сервера всех баз - совсем не хочется.

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

netwind, да на сотню серверов (да и на 10 в общем то тоже) я не замахиваюсь, но заложить в архитектуру возможность использовать хотя бы второй сервер для этой таблицы - все же нужно.

Восьмибитного автоинкрементного id, разумеется, хватит, чтобы счетчик не переполнился, но физически сервер столько записей и не вместит и уж тем более не сможет быстро обрабатывать. Так что мой топикстартерский вопрос остаётся открытым..