powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Большая таблица (масштабируемость?)
13 сообщений из 38, страница 2 из 2
Большая таблица (масштабируемость?)
    #39137701
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
мы получаем данные из чёрного ящика по апи, в котором они приезжают именно в таком виде.


Но никто не обязывает вас хранить данные именно в этом виде.
...
Рейтинг: 0 / 0
Большая таблица (масштабируемость?)
    #39137704
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Barvinok,
короче, главная проблема - отсутствие компетенции в проектировании баз данных и создании приложений для них.

и MySQL тут точно мимо. не потянет.
...
Рейтинг: 0 / 0
Большая таблица (масштабируемость?)
    #39137714
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
можно рассчитывать на то, что работа с индексами бинарных блобов как-то лучше, чем у строк?

--
нет, нельзя.
--

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

--
проблемой является не только место само по себе, но и скорости обработки таких объемов данных. объемы немаленькие, а чем больше объем, тем дольше и сложнее он обрабатывается.
...
Рейтинг: 0 / 0
Большая таблица (масштабируемость?)
    #39137716
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Barvinokmiksoftпропущено...
BINARY(16) - это не блоб, это та же строка, только которая не подвергается преобразованиям кодировок. Т.е., грубо говоря, это CHAR без кодировки.
ну почему же это строка?
вот типичный вид гуида из игры, как он приезжает через апи:
Код: plaintext
7bddc559e95e4aaebbb846dc925962f5.c
здесь 32 шестнадцатеричных символа и ".c" - признак того, что это гуид игрока.
теперь вы предлагаете хранить её как BINARY(16), т.е. это уже строкой перестаёт быть и становится бинарным фрагментом что-ли.
да, это займёт меньше места, но точно ли поиск по бинарным данным лучше чем по строке?

поиск не будет быстрее, но быстрее будет все чтения, потому, что размер данных будет в два раза меньше.
...
Рейтинг: 0 / 0
Большая таблица (масштабируемость?)
    #39137729
netwind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivпроблемой является не только место само по себе, но и скорости обработки таких объемов данных. объемы немаленькие, а чем больше объем, тем дольше и сложнее он обрабатывается.
Это не традиционное приложение, а просто хранилище логов.
Все отлично будет с mysql и myisam.
...
Рейтинг: 0 / 0
Большая таблица (масштабируемость?)
    #39137940
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
netwindMasterZivпроблемой является не только место само по себе, но и скорости обработки таких объемов данных. объемы немаленькие, а чем больше объем, тем дольше и сложнее он обрабатывается.
Это не традиционное приложение, а просто хранилище логов.
Все отлично будет с mysql и myisam.

пофигу, что это за приложение.
а про какую-то там аналитику ТС и сам говорил.
...
Рейтинг: 0 / 0
Большая таблица (масштабируемость?)
    #39137944
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivnetwindпропущено...

Это не традиционное приложение, а просто хранилище логов.
Все отлично будет с mysql и myisam.

пофигу, что это за приложение.
а про какую-то там аналитику ТС и сам говорил.

не дописал....
такие объемы данных с индексом и загрузить уже будет трудно, а без индексов - бесполезно.
...
Рейтинг: 0 / 0
Большая таблица (масштабируемость?)
    #39138086
netwind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv, переусложняете. Я просто знаю какое применение у этой базы.
...
Рейтинг: 0 / 0
Большая таблица (масштабируемость?)
    #39138530
Barvinok
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
netwindMasterZiv, переусложняете. Я просто знаю какое применение у этой базы.
внезапно O_O
ладно, чего уж там прятаться...
вот так она выглядит после (я надеюсь) нормализации, в полном виде:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
CREATE TABLE `n_eventlog` (
	`eid` BIGINT(20) UNSIGNED NOT NULL COMMENT 'Event Mapped-ID',
	`timestamp_raw` BIGINT(20) UNSIGNED NOT NULL COMMENT 'UNIX epoch in milliseconds',
	`event_faction` ENUM('ALIENS','RESISTANCE') NOT NULL COMMENT 'Event faction',
	`origin_type` ENUM('PLAYER','SENDER','SECURE') NOT NULL COMMENT 'Event origin type',
	`pid` INT(10) UNSIGNED NOT NULL COMMENT 'Originating Player Mapped-ID',
	`player_faction` ENUM('ALIENS','RESISTANCE') NOT NULL COMMENT 'Originating player faction',
	`loc1_id` INT(10) UNSIGNED NULL DEFAULT NULL COMMENT 'Location 1 Mapped-ID',
	`loc1_lat` DECIMAL(9,6) NULL DEFAULT NULL COMMENT 'Location 1 latitude',
	`loc1_lng` DECIMAL(9,6) NULL DEFAULT NULL COMMENT 'Location 1 longitude',
	`loc2_id` INT(10) UNSIGNED NULL DEFAULT NULL COMMENT 'Location 2 Mapped-ID',
	`loc2_lat` DECIMAL(9,6) NULL DEFAULT NULL COMMENT 'Location 2 latitude',
	`loc2_lng` DECIMAL(9,6) NULL DEFAULT NULL COMMENT 'Location 2 longitude',
	`event_action` ENUM('CAPTURE','LINK','FIELD','NOLINK','NOFIELD','FRACKER','BEACON') NULL DEFAULT NULL COMMENT 'Event action',
	`deltaMU` BIGINT(20) NOT NULL DEFAULT '0' COMMENT 'Delta MU',
	`event_type` ENUM('PLAYER_GENERATED','SYSTEM_BROADCAST') NOT NULL COMMENT 'Event type',
	`event_category` TINYINT(3) UNSIGNED NOT NULL COMMENT 'Event category',
	PRIMARY KEY (`eid`),
	INDEX `key_pid` (`pid`),
	INDEX `key_loc1_id` (`loc1_id`),
	INDEX `key_loc2_id` (`loc2_id`),
	INDEX `timeline` (`timestamp_raw`)
)
COMMENT='Global event log (normalized)'
COLLATE='utf8_general_ci'
ENGINE=MyISAM
;


постарался учесть все ваши замечания, только вынес отображение гуида на иды в три отдельные таблицы, а не одну.
теперь такие вопросы:
1) написал скрипт разбора старого лога в новую схему таблицы, обработал пробный миллион событий и смотрю - размер 137.2 MiB, индексы 77.2 MiB. Это нормально? ну, то есть, я конечно рад, что таблица будет занимать 56 GiB вместо 145 GiB, но какой же тогда будет индекс? :(
2) далее, отображения сделаны так, например, для игроков
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
CREATE TABLE `idmap_players` (
	`id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 'Mapped ID',
	`guid` BINARY(16) NOT NULL COMMENT 'Related GUID',
	`name` VARCHAR(20) NOT NULL COMMENT 'Related NAME',
	PRIMARY KEY (`id`),
	UNIQUE INDEX `key_player` (`guid`, `name`)
)
COMMENT='Contains ID to GUID+name map for players'
COLLATE='utf8_general_ci'
ENGINE=MyISAM
AUTO_INCREMENT=1
;


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

но тут проблема - я не знаю, как правильно написать INSERT ODKU, чтобы при срабатывании по дубликату можно было получить id, под которым этот дубликат там уже был ранее записан (ничего в самой таблице не меняя).
сейчас я просто пишу отдельный SELECT, но это как-то криво и медленно. подскажите, пожалуйста.

3) наконец, с ростом новой таблицы падает скорость заполнения. мы только перешагнули за миллион, а уже на глаз притормаживает раза в полтора-два. есть какие-то стандартные способы борьбы с этим?
...
Рейтинг: 0 / 0
Большая таблица (масштабируемость?)
    #39138536
netwind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
я так и не понял зачем вообще хранить основной guid события ? он же не нужен.
Нужен порядковый номер и прочие атрибуты.

автор3) наконец, с ростом новой таблицы падает скорость заполнения. мы только перешагнули за миллион, а уже на глаз притормаживает раза в полтора-два. есть какие-то стандартные способы борьбы с этим
стандартные все те же - денормализация
из "запрещенных" можно попробовать DELAY_KEY_WRITE = 1; и файловую систему без журнала смонтировать.
Если вы арендуете сервер (а где вы вообще нашли физиеский сервер на 2гб) на нормальной площадке, там же никто не перезагружает его внезапно.
Транзакции и надежная фиксация данных на диск не нужна.. Опять же, исходя из того как я представляю себе ценность данной информации.
...
Рейтинг: 0 / 0
Большая таблица (масштабируемость?)
    #39138538
Barvinok
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
чёрт возьми, случайно отправил незаконченное сообщение.
а функции редактирования на этом форуме нет? :(

netwindя так и не понял зачем вообще хранить основной guid события ? он же не нужен.
Нужен порядковый номер и прочие атрибуты.
так и будет потом, когда мы пересоберём тот старый евентлог.
дело в том, что при экспериментах с ним была залита часть событий дублирующих уже существующие, поэтому нужно будет отфильтровать их обязательно.

автор3) наконец, с ростом новой таблицы падает скорость заполнения. мы только перешагнули за миллион, а уже на глаз притормаживает раза в полтора-два. есть какие-то стандартные способы борьбы с этим
стандартные все те же - денормализация
из "запрещенных" можно попробовать DELAY_KEY_WRITE = 1; и файловую систему без журнала смонтировать.
Если вы арендуете сервер (а где вы вообще нашли физиеский сервер на 2гб) на нормальной площадке, там же никто не перезагружает его внезапно.
сервер физический у меня на кухне стоит.

п.3. вопроса я снимаю, с ODKU вроде бы разобрался сам.
...
Рейтинг: 0 / 0
Большая таблица (масштабируемость?)
    #39138643
netwind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Barvinok, я бы не стал делать в таком случае DELAY_KEY_WRITE. Не очень надежно и myisam чинить потом долго.
Проц очень уж слабый для LGA775. Там были намного лучше варианты. Это как раз влияет на создание индексов и починку таблиц.
Но вы можете временные сервисные действия на хорошем ПК c SSD выполнять, а постоянно эксплуатировать "на кухне".
...
Рейтинг: 0 / 0
Большая таблица (масштабируемость?)
    #39138646
netwind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
еще есть такая тема : на LGA775 покупается в Китае хит прошлых лет Xeon X5460 примерно за 2500 руб и наслаждаетесь.
Но это спорный вариант. Не понятно насколько долго его хватит.
...
Рейтинг: 0 / 0
13 сообщений из 38, страница 2 из 2
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Большая таблица (масштабируемость?)
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]