Потому что эта самая эфективная и простая организация массива. Вам не нужно высчитывать в каком блоке что находится, используете один индекс. Проблем с выделением не одним блоком нет — на х64 система отдавала 7,6 Гб при физических 4, дальше я пробовать не стал.
Ок, согласен — равными блоками получится. Мы потратим еще немного на их организацию. По сути это то же что и сейчас, только блоки неравные и соответсвуют хешу. Нужно экспериментировать, но боюсь сортировка 100 млн. обойдется гораздо дороже подсчета хеша и поиска в цепочке.
Возникает вопрос: как это все поддерживать, отлаживать и т.д. Тут много нюансов, например сборка AnyCPU будет работать и на х32 и на х64 в родном режиме, а для native кода прийдется делать уже две сборки.
Я не уверен, что готовое решение будет очень оптимальным, оно скорее всего универсально и в подобной задаче может проиграть. Я не использовал memcached, но мне просто интересно, сколько она займет памяти на таких объемах.
Дико извиняюсь — я новичок тут у вас. Не осилил предмет. В помощи указано юзать тег source, но он не работает. В редакторе code, но без подсветки. Подскажите как правильно?
Нам не нужно постоянно хранить. Хранятся они действительно в БД. Нужно было сравнивать новые вхождения с тем что в БД, на таких объемах Оракл задачу выполняет, но достаточно медленно. Поэтому перевели на память.
По производительности и по распределению она нас полностью устроила. По сути это не было самим узким местом и мы не стали искать другие варианты. Спасибо, гляну ELF.
Я не уверен, что готовое решение будет очень оптимальным, оно скорее всего универсально и в подобной задаче может проиграть. Я не использовал memcached, но мне просто интересно, сколько она займет памяти на таких объемах.