Comments 16
Хотя бы пару слов про скорость чтения…
Мне сложно представить задачу, в которой вставка в дерево является единственной задачей (или основной).
Мне сложно представить задачу, в которой вставка в дерево является единственной задачей (или основной).
Ерунда. Если надо хранить в базе, будут хранить в базе. Туда влезет сколько угодно данных.
По производительность базы читать тоже смешно. В высоконагружённых приложениях все затыкается в скорость ввода-вывода с диска, т.е в БД. Поэтому сравнение с in memory Map бессмысленно.
По производительность базы читать тоже смешно. В высоконагружённых приложениях все затыкается в скорость ввода-вывода с диска, т.е в БД. Поэтому сравнение с in memory Map бессмысленно.
> Если надо хранить в базе, будут хранить в базе.
А где в статье было сказано про необходимость долгосрочного хранение данных?
>В высоконагружённых приложениях все затыкается в скорость ввода-вывода с диска
Поэтому и можно использовать данное решение, чтобы не упираться в скорость диска.
>Поэтому сравнение с in memory Map бессмысленно.
А где в статье делается сравнение с БД?
А где в статье было сказано про необходимость долгосрочного хранение данных?
>В высоконагружённых приложениях все затыкается в скорость ввода-вывода с диска
Поэтому и можно использовать данное решение, чтобы не упираться в скорость диска.
>Поэтому сравнение с in memory Map бессмысленно.
А где в статье делается сравнение с БД?
Вы вообще не поняли, о чем речь. Бессмысленно сравнивать объем данных, которые можно сохранить в памяти и на диске.
Аффтар статьи почему-то решил сравнить хранение в памяти с дисковым хранением, причем именно по параметру вмещаемых данных.
Аффтар статьи почему-то решил сравнить хранение в памяти с дисковым хранением, причем именно по параметру вмещаемых данных.
Где вы в статье вообще нашли дисковое хранение?
Еще один.
«Java MapDB provides concurrent TreeMap and HashMap backed by disk storage. It is a fast, scalable and easy to use embedded Java database.»
github.com/jankotek/MapDB
Вас в Гугла забанили или с соображалкой также плохо, как у автора статьи?
«Java MapDB provides concurrent TreeMap and HashMap backed by disk storage. It is a fast, scalable and easy to use embedded Java database.»
github.com/jankotek/MapDB
Вас в Гугла забанили или с соображалкой также плохо, как у автора статьи?
А глубже глянуть не судьба? Или хотя бы посмотреть на название метода, которой вполне даже самодокументируем?
Или вы как-то по-другому переводите in-memory?
/** Creates new in-memory database. Changes are lost after JVM exits.
* <p/>
* This will use DirectByteBuffer outside of HEAP, so Garbage Collector is not affected
*
*/
public static DBMaker newDirectMemoryDB(){
DBMaker m = new DBMaker();
m._file = null;
m._ifInMemoryUseDirectBuffer = true;
return m;
}
Или вы как-то по-другому переводите in-memory?
Кстати, не каждая БД (даже NoSQL) сможет показать такую скорость: «It also has outstanding performance with 1 million inserts per second and 10 million fetches per second (disk based!!).»
Что за ужасный перевод? И где ссылка на оригинал?
Я за минуту нагуглил вот это:
kotek.net/blog/3G_map
Скорее всего, есть более ранние версии того же текста.
Я за минуту нагуглил вот это:
kotek.net/blog/3G_map
Скорее всего, есть более ранние версии того же текста.
m.put(counter,"");
Все ключи будут указывать на один и тот же объект в памяти? С первого взгляда кажется, что для произвольного Map это тест проверяет только расход пямяти на ключи, но не на значения.
Одним дождливым вечером я размышлял о памяти менеджмент в Java и как эффективно использовать Java коллекции. Я сделал простой эксперимент, сколько записей я могу вставить map с 16 Гб оперативной памяти?
Бот гуглотранслейта получил инвайт на хабр?
Перевод ужасный, но статья интересная, как раз хотел сам писать нечто подобное, а тут готовое решение :) Эх, надо над рабочем местом повесить «Поищи вначале на github!»
Sign up to leave a comment.
3 миллиарда записей в Java Map на 16 GB RAM