История изменений

Вот с этого я и начинал, да. Так гораздо проще быстрее работать. Но есть нюанс. Это луа5.1, где количество элементов ограничено 232 тысячами. Представь, допустим 10 таблиц по 100 элементов на пользователя. Это 1000 клюей, 1000 строк-значений. Плюс доп настройки, плюс доп элементы. На каждого. Всего сто пользователей и у тебя уже от ста тысяч таких элементов. При экономии все падает на 3-4 тысячах пользователей.

А падает оно, обнуляя все таблицы. Просто в nil. Все таблицы всех аддонов. Правда здорово? Все данные.

Если объединить такую таблицу из ста элементов в одну строку, количество возможных пользователей увеличивается в сто раз и становится более менее юзабельным. Но появляются нюансы обработки.

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

Заметь, я даже не использую ключи. У меня не хэш-таблицы. У меня просто массив строк. Это экономия 20-30% места, что на большом объеме данных очень неплохо. И работа с номерами строк, а не ключами.

Вот обрати внимание на твой вариант структуры. Это СТО таблиц базово вместо одной строки. Каждая таблциа 40 байт. Умножай на пользователя. В каждой таблице по две строки по 17 байт плюс данные… Это плюс двести строк. Плюс двести ключей по 17 байт плюс данных.. У меня все аж зачесалось от такой структуры, ибо я пробовал такое даже в более оптимальном варианте. И даже в более оптимальном варианте все рухнуло в итоге.

Вот с этого я и начинал, да. Так гораздо проще быстрее работать. Но есть нюанс. Это луа5.1, где количество элементов ограничено 232 тысячами. Представь, допустим 10 таблиц по 100 элементов на пользователя. Это 1000 клюей, 1000 строк-значений. Плюс доп настройки, плюс доп элементы. На каждого. Всего сто пользователей и у тебя уже от ста тысяч таких элементов. При экономии все падает на 3-4 тысячах пользователей.

А падает оно, обнуляя все таблицы. Просто в nil. Все таблицы всех аддонов. Правда здорово? Все данные.

Если объединить такую таблицу из ста элементов в одну строку, количество возможных пользователей увеличивается в сто раз и становится более менее юзабельным. Но появляются нюансы обработки.

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

Заметь, я даже не использую ключи. У меня не хэш-таблицы. У меня просто массив строк. Это экономия 20-30% места, что на большом объеме данных очень неплохо. И работа с номерами строк, а не ключами.

Вот обрати внимание на твой вариант структуры. Это СТО таблиц базово вместо одной строки. Каждая таблциа 40 байт. Умножай на пользователя. В каждой таблице по две строки. Это плюс двести строк. Плюс двести ключей. У меня все аж зачесалось от такой структуры, ибо я пробовал такое даже в более оптимальном варианте. И даже в более оптимальном варианте все рухнуло в итоге.