Key/value значения. Как выбрать оптимальный способ хранения?

Question

[vanilich]

Доброго времени суток.
Разрабатываю Web-приложение (подробности опущу), где понадобилось скрывать реальные пользовательские ID (Primary Key в MySQL) за строкой фиксированной длины (хэшем). Хэши случайным образом генерируются при регистрации и заносятся в таблицу users_hashes вида:
| unique_hash | user_id |

Пример, где я это буду использовать:
Допустим, пользователь1 отправляет сообщение пользователю2, посредством ajax на сервер. Запрос выглядит так:

{
  "from": "c1fedb2d17ca40af1c27252646d8be48",
  "to": "7f5215959290e8ec6626e904d9e84648",
  "message": "some message..."
}

Сообщение приходит на сервер, где я должен найти такой же хэш в таблице "users_hashes" и вытащить соответственный ему ID пользователя, только затем поместив сообщение в бд. Я понимаю, что каждая такая выборка (хоть и не много), но будет нагружать сервер.

Короче, мне надо чтобы пользователь не узнал о своем ID (Детали проекта, к сожалению, разглашать не могу). И сделать весь этот процесс как можно более эффективным и быстрым.

Первая мысль, которая пришла в голову - это кэшировать полученные значения из users_hashes допустим в Memcache, и как раз вытаскивать ID пользователя по хэшу.

Буду благодарен любому ответу и конструктивной критике.

Answer 1

[IvanSenishin]

Еще можно использовать redis

Comments

[Дмитрий Энтелис]

+1, гораздо лучше чем memcache

[vanilich]

Я рассматривал этот вариант. Но пока не решался браться за него, т.к. очень мало знаю о нем. Думаю - пришло время узнать что-то новое.

Answer 2

[Руслан Федосеев]

ну в memcache и храните. Только.... А какая принципиальная разница между "мой id 6644" и "мой id c1fedb2d17ca40af1c27252646d8be48" ?

Comments

[prishelec]

Тоже не пойму разницы.

[Дмитрий Энтелис]

id скрывают наиболее часто в случае когда хотят скрыть реальный размер аудитории)

[Руслан Федосеев]

ну разве что ;)

[Руслан Федосеев]

id = rand(100000);
вполне хватит ;)

[vanilich]

Руслан Федосеев: в случае с rand, существует же вероятность того, что два пользователя получат один и тот же ID.

[vanilich]

Сергей Сергеев: честно говоря, даже и не думал об этом варианте. Спасибо.

[Руслан Федосеев]

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

[Дмитрий Энтелис]

Сергей Сергеев: зарегистрировав подряд несколько пользоветелей - можно легко увидеть эту закономерность. Вариант с rand имеет право на жизнь, если маркетинг не смущают именно цифровые ид.

[Руслан Федосеев]

есть такой принцип KISS ;)
в принципе можно генерацию ID через численное решение системы дифуров делать )

Ну да лано, не об этом вопрос.
Сейчас вопрос сформулирован так - не хочу простые числовые id, хочу сложные в виде хеша. Отговорка "чтобы пользователь не узнал свой id" - не при чем. Если хотите убрать упорядоченность id, чтобы нельзя было извлечь никакой информации - выберите другой принцип генерации id - случайно, по хитрой формуле, guid, хеш от чего нить....

[Руслан Федосеев]

Так - да. Но из текста вопроса я понял, что хеш единственный и заменяет id.... Возможно был неправ

Answer 3

[Night]

О каком объеме данных/запросов идет речь?
Если у Вас база меньше 250-300к юзеров, думаю, нет особой разницы где хранить - в мемкэше, или в mysql, в плане скорости и нагрузки.
На мой взгляд, если это не является на текущий момент узким горлышком, то это преждевременная оптимизация.

Comments

[vanilich]

Согласен с вами. Решил подстраховаться и попробовать что то новое :).

[vanilich]

Сергей Сергеев: полез не в ту степь...