Интересная идея. Только надо разработать стратегию динамического увеличения диапазона хэша. Как это сделать эффективно, чтобы не налетель на однократный O(N) при очередной вставке, не вполне понятно.
Это не решит проблемы. Если они сделаны по типу b-tree, то чтобы не жрать в недецких количествах память индексы должны быть кучными, что хрен обеспечишь. Во-вторых, нефигово было бы ограничить длину целого ключа, иначе сильно распухнет индекс. Плюс пойдут тормоза из-за long-int.
Хотя... В моем случае у меня как раз таки есть возможность раздать индексы всем инструментам так, чтобы они были кучными. Надо попробовать.
Нет, черт возьми. Так нельзя. Даже если массив будет быстрым (в чем я лично сомневаюсь), это вынудит выполнять преобразование из имени инструмента в номер на парсинге, а это полная задница. Потому, что этот маппинг придется хранить в mnesia. Получим тормоза в парсере котировок.
Можно конечно извратнутся и закэшировать таблицу mnesia в словаре процесса подписавшись на уведомления об изменениях от mnesia (гы! прикольное решение!). Надо подумать об этом изврате, это в принципе вполне себе вариант для реплик таблиц, которые только читаются.
Reply
Reply
Reply
Хотя... В моем случае у меня как раз таки есть возможность раздать индексы всем инструментам так, чтобы они были кучными. Надо попробовать.
Reply
Можно конечно извратнутся и закэшировать таблицу mnesia в словаре процесса подписавшись на уведомления об изменениях от mnesia (гы! прикольное решение!). Надо подумать об этом изврате, это в принципе вполне себе вариант для реплик таблиц, которые только читаются.
Reply
Leave a comment