Организовать систему лайков и репостов к сообщениям пользователей как в vk

Доброе время суток.

Мне нужно организовать систему лайков и репостов к сообщениям пользователей как в vk.
Сайт написан на C++, часто запрашиваемые данные хранятся в оперативной памяти.
Никаких баз данных не использую. Есть только файлы.
ID сообщения занимает 8 байт памяти.
ID пользователя - 4 байта.
Нужно максимально быстро с минимальными затратами памяти, процессорного времени и минимальным износом SSD реализовать 3 функции:
1 - добавить лайк
2 - удалить лайк
3 - проверить ставил ли я лайк

Как лучше реализовать с расчётом на то, что лайков как у сообщения, так и у пользователя может быть очень много?
Может есть какие ссылки?
Особенно интересно как это реализовал Дуров в vk.

0

Сообщение от Krocker Сайт написан на C++

Эм ЭТО КАК?
Браузер написан на Си, но язык разметки(интерпритация) это html и php (вроде бы)...

0

Это значит, что http демон и websocket сервер написаны на C++. HTML разметка для выдачи браузеру собирается сишным кодом. По сравнению с PHP удалось увеличить скорость обработки запросов в сотни раз.

0

Сообщение от Krocker Это значит, что http демон и websocket сервер написаны на C++. HTML разметка для выдачи браузеру собирается сишным кодом. По сравнению с PHP удалось увеличить скорость обработки запросов в сотни раз.

Вот здорово. Глянуть бы еще на это все. Особенно на сводные таблицы последнего.

0

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

Ну допустим, что мы "опустим" саму страницу, а предположим что это WINAPI окно, в котором например нужно сделать подобное. Тогда нужно знать когда будет запрашиваться система лайков.
Грубо я представляю это так как выглядит на сайтах: вы видите сообщение, при его выводе сразу выводится в низу окошко с лайками(только количество проголосовавших - т.е. базовая инфа). Если нужно узнать подробнее - то клик по окошку и выводится(как в "моём мире") доп окно, в которых список проголосовавших.
Т.е. исходя из этого, имеем файл с лайками. По ID сообщения находим строку в файле лайков, где первой переменной будет общее число лайков(типа int), и далее в строке(а лучше сделать подстроку, чтоб когда строку в файле читаеш - не читать лишнее) будут ID пользователей, поставивших лайк.
Думаю для быстроты работы и поиска в файле ID, нужен алгоритм поиска.. Ну тут уж нужно включить фантазию, например иметь несколько файлов с ID, упорядоченными, при этом например в первой строке каждого файла писать ID и его число соответствующее байту в файле(чтоб сразу перейти с помощью fseek к примеру)
Вот по трём пунктам конешно можно поэкперементировать... Я бы на вашем месте взял бы чистую тетрадку и начал бы примерно планировать как сделать соотношение "цена-качество".
Функции для манипуляций с лайками делайте(или одну функцию с переменной enum типа для опр. действия) ну и в ней уж пишите алгоритм.
Хотя честно скажу, я ещё "лошара", опыта не так много чтоб давать советы по оптимизации, по мне так простота понимания кода - самое главное, а остальное по мере поступления задач.

0

Сообщение от SatanaXIII Глянуть бы еще на это все.

Там кода уже больше мегабайта и он секретный. Глянуть можно примеры в библиотеках boost. В них есть примеры простых веб серверов. Их легко научить хранить данные сообщений и пользователей в оперативной памяти и вместо формирования SQL запросов к базе данных просто считывать информацию по определённому адресу в оперативной памяти.

Сообщение от SatanaXIII Особенно на сводные таблицы последнего.

Если речь про скорость обработки, то корректное сравнение провести не могу. Могу лишь выдать данные времени обработки от получения сырого GET запроса, до выдачи готового кода.
Если нужно читать информацию с диска, то обработка запароса занимает от 00:00:00.0001 (одна десятитысячная секунды), до 00:00:00.002
Если данные уже в оперативной памяти, то отсчёт идёт от 00:00:00.000007
Это только одним ядром процессора.

Сообщение от Izual имеем файл с лайками

На данный момент число лайков хранится в оперативной памяти и лишь изредка весь массив данных скидывается на диск.
Если к каждому сообщению делать отдельный фаил с лайками, то файл с одним лайком(4 байта бинарной информации) на диске займёт несколько килобайт, что очень не эффективно. Пока придумал огород из 3х типов общих файлов. В каждом из них резервируется определённое место, куда будут записаны ID пользователей. После переполнения это место освобождается под лайки другого сообщения, а текущие лайки переносятся в фаил попросторнее. Если переполнятся в последнем файле, то будет создан отдельный фаил с лайками для определённого сообщения.
При лайке массив данных загружается в std::set<unsigned int> , в ней удобно искать добавлять и удалять данные, и какое-то время хранится в оперативной памяти как горячие данные, если в течении этого промежутка никто не запрашивал данные, то они сбрасываются на диск. Если были ещё лайки то время хранения данных продливается. Потом всё за 1 раз сбрасывается на диск.

0

Сообщение от Krocker Если к каждому сообщению делать отдельный фаил с лайками

Я такого не говорил. Я сказал так:

Сообщение от Izual По ID сообщения находим строку в файле лайков

Т.е. файл не отдельный для каждого месаджа, а файл например один на пользователя, в нём все сообщения и лайки...

0

Krocker, нельзя сказать, что я знаток данной технологии, но мне прям видятся сразу две огромные стандартные проблемы хранения данных в оперативной памяти:
- что будет с ними, когда память закончится? В виртуальную область перемещаться? А чем тогда файл/бд не нравятся?
- что будет с ними при аварийном падении сервера?

Сообщение от Krocker то файл с одним лайком

Вот как раз для этого и придумали файлы баз данных.

0

Сообщение от SatanaXIII - что будет с ними, когда память закончится? В виртуальную область перемещаться? А чем тогда файл/бд не нравятся?

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

Сообщение от SatanaXIII - что будет с ними при аварийном падении сервера?

Важные данные вначале сохраняются на диск. С ними ничего не будет. Некоторые счётчики и сессии пользователей могут быть утеряны, но пользователю легко перелогиниться, а счётчик, например, лайков, может быть восстановлен. При загрузке ID лайкнувших пользователей, число записей пишется в значение счётчика.

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

0

Сообщение от Krocker БД не нравится тем, что это сторонняя разработка со множеством ненужных функций, которую нужно отдельно устанавливать, обновлять и запоминать документацию. Проще один раз запомнить принципы хранения и поиска информации.

Необязательно вкрячивать оракл для двух табличек. К примеру SQLite позволит вам все тоже самое, что вы хотите, но при этом не придется врукопашную заниматься работой с файлами. Устанавливать не нужно, ненужными функциями не пользуйтесь, справку по ним тоже не читайте - разве не хорошо?
Конечно, придется сперва вникнуть в принципы ее работы, но столько же времени уйдет и на написание своего обработчика всего этого дела.
Если вы уверены, что ваши подходы и методы лучше, чем то, что уже было разработано и отлажено, да и успешно применяется уже длительное время, тогда да, тогда используйте свои.

Сообщение от Krocker Важные данные вначале сохраняются на диск.

Ну и чем этот подход отличается от работы с файлами?

0

Сообщение от SatanaXIII да и успешно применяется уже длительное время, тогда да, тогда используйте свои.

Предпочту свои алгоритмы работы с информацией.

Сообщение от SatanaXIII Ну и чем этот подход отличается от работы с файлами?

Файлы баз данных или просто файлы с примитивно структурированной информацией?
О том, что использую простые файлы писал ещё в первом посте.
В случае с файлами баз данных, таких, как в MySQL, расписывать всё по порядку нет времени. Я уже экспериментировал в предыдущей версии сервера с MySQL и понял, что гораздо быстрее сбросить кусок оперативной памяти в фаил и считать обратно, чем готовить SQL запросы, ждать ответа от базы данных и конвертировать ответ обратно в структуру. Ещё отсутствует возможность взлома через SQL инъекцию.

0

Сообщение от Krocker сбросить кусок оперативной памяти в фаил и считать обратно, чем готовить SQL запросы, ждать ответа от базы данных и конвертировать ответ обратно в структуру. Ещё отсутствует возможность взлома через SQL инъекцию.

На каждый ваш довод можно приводить противоположный.

В общем, если считаете правильным - делайте. Это вещь полезная.

0