Может кто-нибудь объяснить, как мы реализуем простые хранилища ключей / значений с помощью MySQL?

Question

http://royal.pingdom.com/2010/06/18/the-software-behind-facebook/:

Facebook использует MySQL, но в основном как постоянное хранилище с ключом-значением, перемещая соединения и логику на веб-серверы, поскольку там легче выполнять оптимизацию (на "другой стороне" слоя Memcached).

Может кто-нибудь объяснить, как мы реализуем простые хранилища ключей / значений с помощью MySQL? Это просто таблица с bigint в качестве первичного ключа + один столбец LONGTEXT?

Answer 1

Отправной точкой должно быть "ваши данные реляционные?" Если это так, используйте реляционную базу данных!

Ключ-значение - отличное решение для нереляционных данных, но если ваши данные являются реляционными, используйте SQL и покончите с этим.

Answer 2

Чтобы ответить на ваш первый вопрос, да, хранилище ключ / значение - это просто, вы храните ключ и значение, связанное с этим ключом. И вы делаете запрос на основе ключа.

Большие преимущества, которые вы получаете от этого,

• Масштабируемость. Теперь вы можете легко распределять свои данные по многим (тысячам) машинам. Это то, что традиционная СУБД не очень хороша, соединения и гарантии кислотности на многих машинах либо невозможны, либо очень-очень медленные.

Facebook также имеет много данных, которые не соответствуют модели отношений, которую использует обычная СУБД, а именно графики. Это означает, что они сами запрашивают / хранят / обрабатывают графическую природу данных, а не обрабатывают с помощью SQL.

Стоимость такого подхода сложна, и часто вам приходится отказываться от нескольких пунктов свойств ACID.

Остальные из нас, это не facebook/google/linkedin/ и т. Д. что для работы с сайтами, насчитывающими до нескольких миллионов пользователей, обычно достаточно просто использовать традиционную базу данных.