VR
тогда надо ещё бояца — из тезиса следует 🤷♂️
Size: a a a
2021 August 20
VF
Есть случаи когда некоторым людям приходится переписывать заново базовые вещи, в том числе и хэши. Это мое утверждение. Я считаю, что это очень хорошо. Пусть переписывают.
ii
Случаи очень редкие. В большинстве ограниченные аппаратными ресурсами
VF
Ну "бывает нужно", я так и сказал в самом начале
VF
Накидали годных примеров, спорщики могут оспорить примеры? Раскритиковать их, так сказать?
МС
такое бывает, но есть ещё фактор наличия ресурсов
VR
да, с такими случаями сталкивался 👍
VR
Виктор, да вот не от Вас, к сожалению 😎
VF
Ну и чего вы тогда спорите? С чем? С какими моими утверждениями?
VF
Почему к сожалению? 🤓
VR
с необоснованными )
VF
Хэшмап на диске, я привел пример, очень даже жизненный
VF
С какими конкретно?
VR
а что такое "хашмап на диске"? )
DZ
+1 к хешмапу на диске - довольно интересная штука оказывается. Ну или дерево на диске.
Возможно самому придётся скоро писать - потому что упёрлись в железо
Возможно самому придётся скоро писать - потому что упёрлись в железо
VR
зачем разработчику решать задачу хранения чего-либо на диске средствами ЯП? это же комплексная задача — не про диск и не про хашмап =) и реализация (в случае с VM) будет далека от оптимальной. даже хуже, чем embedded redis с персистентностью, нет?
DZ
ну это я образно - нет у нас диска и возиться с ним не хочется - хочется в качестве shared storage использовать s3, а в качестве shared memory dynamodb и на этом построить большое быстрое и дешёвое резиновое дерево
МС
мне кажется это зависит от ЯП, если это языки на VM, то лучше не надо
VR
а дерево для чего требуется? быстрое и резиновое? 🤔 свалить всё в одну кучу, чтобы потом в нём оптимизацию поиска придумывать?
DZ
Ну скорее у нас есть несколько сотен тысяч деревьев, от 10 до нескольких миллионов элементов в каждом, и надо быстро уметь отвечать на range запросы