Кэширование данных из БД MySQL - техника и соответствующий контейнер STL?

Question

Я проектирую систему кэширования данных, которая может содержать очень большое количество записей одновременно, и мне нужно знать, какой контейнер stl использовать и как его использовать.Дело в том, что у меня очень большая БД записей для пользователей - когда они входят в мою систему, я хочу получить их записи и кэшировать некоторые данные, такие как имя пользователя и несколько важных свойств.Когда они взаимодействуют с системой, я обновляю и получаю доступ к их свойствам.Некоторые свойства очень изменчивы, и я делаю это, чтобы избежать "ударов" по БД со многими транзакциями.Кроме того, мне редко нужно использовать базу данных для сортировки или чего-то еще - я использую это как прославленный бинарный файл сохранения (вот почему я счастлив кешировать записи в память ..);более важной целью для меня является возможность масштабирования до огромного числа пользователей.

Когда пользователь выходит из системы, сервер отключается, или периодически в циклическом режиме (на всякий случай ..) , я хочу записать свои данные обратно в БД.

Сервер сохраняет свои собственные:

vector <UserData *> loggedInUsers;

С UserData сохраняются такие вещи, как имя пользователя (строка) и другие свойства изБД, а также другие временные данные, такие как сетевые дескрипторы.

Мой первый вопрос: если мне нужно найти конкретного пользователя в этом векторе, каков самый быстрый способ сделать это, и есть ли другой контейнер stl, который я могу использовать, чтобы сделать это быстрее??Теперь я создаю итератор, запускаю его в loggedInUsers.begin () и перебираю в .end (), проверяю * iter-> username == "foo" и возвращаю, когда он найден.Если имя пользователя находится в конце вектора, или если вектор имеет 5000 пользователей, это значительная задержка.

Мой второй вопрос: как я могу циклически планировать эти данные для обратной записи вБД?Я могу вызывать функцию каждый раз, когда я готов записать несколько записей в БД.Но я не могу держать итератор для вектора, потому что он станет недействительным.То, что я хотел бы сделать, это иметь вращающуюся очередь, где я могу получить доступ к началу очереди, сохранить ее в БД, а затем повернуть, чтобы она стала концом очереди.Это похоже на большие издержки ... какой тип я мог бы использовать, чтобы сделать это лучше?

Мой третий вопрос: я использую сервер MySQL и libmysqlclient connector / C .. есть ли какие-либо встроенныекеширование, которое могло бы решить эту проблему "бесплатно", или вообще существует другая техника?Я открыт для предложений

Answer 1

A1.вам лучше с картой, это дерево, которое делает поиск для вас.Протестируйте с картой и (при условии, что у вас есть правильный компилятор) или hash_map (который делает то же самое, но механизм поиска отличается).Они имеют разные характеристики производительности для разных типов рабочих нагрузок хранения данных.

A2.Список, вероятно, был бы лучше для вас - выдвинуть вперед, снять конец.(также можно использовать deque, но вы не можете сохранить итератор, если вы удалите его, вы можете с помощью списка). push_back и pop_front (или наоборот) позволят вам поддерживать непрерывную очередь кэшированных данных.

A3.Вы можете попробовать SQLite, которая является мини-базой данных, разработанной для простых нужд хранения на уровне приложения.Он может работать полностью в памяти тоже.

Answer 2

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

При этом ... вам может быть лучше использовать карту (http://www.cplusplus.com/reference/stl/map/)с именем пользователя в качестве ключа.

С точки зрения записи его обратно в базу данных, почему бы не сохранить отдельную структуру (очередь), которую вы можете очищать каждый раз, когда записываете ее в базу данных?храня указатели, он не будет использовать намного больше памяти. Что приводит меня к ... вместо того, чтобы использовать указатели, вы должны взглянуть на умные указатели (например, boost's shared_ptr ), которые позволяют вам передавать их безбеспокоиться о собственности.