Генерация осколков и идентификаторов как instagram

Мой вопрос заключается в том, как генерировать идентификатор для оштукатуренной среды. Я выполняю те же шаги, что и instagram для создания уникальных идентификаторов. У меня есть несколько вопросов о реализации этого поколения id в MySQL.

Вот как генерируется идентификатор (это хранимая процедура PGQL.)

CREATE OR REPLACE FUNCTION insta5.next_id(OUT result bigint) AS $$ DECLARE our_epoch bigint := 1314220021721; seq_id bigint; now_millis bigint; shard_id int := 5; BEGIN SELECT nextval('insta5.table_id_seq') %% 1024 INTO seq_id; SELECT FLOOR(EXTRACT(EPOCH FROM clock_timestamp()) * 1000) INTO now_millis; result := (now_millis - our_epoch) << 23; result := result | (shard_id << 10); result := result | (seq_id); END; $$ LANGUAGE PLPGSQL; CREATE TABLE insta5.our_table ( "id" bigint NOT NULL DEFAULT insta5.next_id(), ...rest of table schema... ) 

Мой вопрос: как я могу это сделать в MySQL (эквивалентный код). Эта хранимая процедура должна вызываться из запроса, чтобы получить следующий идентификатор.

Мой другой вопрос касается запроса осколков. Из того, что я понимаю, они используют логические осколки, которые являются картами для реальных серверов. Если они решили сопоставить логический осколок с новым сервером, это означает, что они должны одновременно запрашивать два сервера для агрегирования результатов, поскольку до того, как они назначили новый сервер для одного и того же логического осколка, некоторые данные были добавлены в более старый сервер. Я просто хотел знать, есть ли лучший способ использовать логические осколки и возможность запросить один сервер, на котором находятся данные, вместо того, чтобы запрашивать все серверы, которые принадлежат и принадлежат к этому логическому осколку?

Благодарю.

    По внешнему виду кода похоже, что вам просто нужно повторить последовательность, вы можете сделать это, создав таблицу в MySQL с помощью AUTO_INCREMENT и используя ее для генерации идентификационных номеров.

    В ScaleBase мы нашли отличный способ обеспечить поддержку автоинкрементов через переменную: SET @@auto_increment_increment=4; ,

    Просто убедитесь, что у каждого осколка есть начальное смещение, и вы свободны. Это прямо, просто, совместимо с существующим MySQL и т. Д.

    Что касается другого вопроса , все данные для одного логического осколка живут только на одном сервере в процессе производства (без учета репликации). Когда у них заканчивается пропускная способность их существующих серверов, они дублируют данные на каждом сервере для последователя и когда новый сервер готов (на данный момент как исходный сервер, так и новый сервер содержат все данные для определенного логического осколка ), они начинают считывать все данные за половину осколков с нового сервера, а другая половина остается на исходном сервере. См. Например, http://www.craigkerstiens.com/2012/11/30/sharding-your-database/ для иллюстрации.

    У меня есть вопрос для программы преобразования, которую я написал, но она, похоже, работает!

    Можно ли безопасно использовать AUTO_INCREMENT в ПЕРЕД ТРИГГЕР в MySQL

    Как только я отвечу на вопрос, я также обновлю этот ответ.

    Версия MySQL:

     CREATE TRIGGER shard_insert BEFORE INSERT ON tablename FOR EACH ROW BEGIN DECLARE seq_id BIGINT; DECLARE now_millis BIGINT; DECLARE our_epoch BIGINT DEFAULT 1314220021721; DECLARE shard_id INT DEFAULT 1; SET now_millis = (SELECT UNIX_TIMESTAMP()); SET seq_id = (SELECT AUTO_INCREMENT FROM information_schema.TABLES WHERE TABLE_SCHEMA = "dbname" AND TABLE_NAME = "tablename"); SET NEW.id = (SELECT ((now_millis - our_epoch) << 23) | (shard_id << 10) | (SELECT MOD(seq_id, 1024))); END 

    Реализация той же логики генерации логики с хранимой процедурой MySQL не представляется возможным. Однако это можно сделать с помощью MySQL UDF .

    Вот UDF, который воссоздает генератор идентификаторов instagrams с несколькими изменениями. Модификация его для работы точно так же, как генератор идентификаторов instagram, включала бы обновление констант MAX_ * и логики смещения бит в next_shard_id и shard_id_to_ms.