LINUX.ORG.RU

Какой вариант расшаривания большого и толстого хеша вы бы предпочли и почему?

 ,


0

1

Что-то вроде опроса среди перловодов :)

Хинт: Структура данных периодически (от раза в 15 секунд до раза в 10 минут) изменяется. Размер структуры данных незначительно, но тоже изменяется. Процессы все в рамках одной машины. Но нет, это не процессы в рамках Apache/mod_perl. «Потребители» читают структуру данных целиком, а потом просто получают её апдейты, поэтому хранить её как-то по частям нет никакого смысла.

Варианты ответов:

1) Засунул бы в ключ NoSQL'я (Redis/Tarantool/MongoDB), засериализовав её в JSON/CBOR/BSON/MessagePack и т.д. - нехай кому надо get'ом забирают.

2) Засунул бы в IPC Shared Memory, пусть из оперативы без посредников качают и десериализуют всё как надо

3) Поднял бы сокет UNIX/TCP - и отдавал бы сериализованное всем желающим по запросу

4) Использовал бы какие-нибудь варианты наподобие очередей и b(lpop) в Redis для организации своеобразного RPC на базе NoSQL-ки

5) Использовал бы File::Map или подобные mmap-штуки, сделав файл изначально процентов на 20 больше сериализованной структуры, чтобы учитывать даже самые зверские флуктуации её размера (как тогда «подрезать» считанное из map'а до реального размера, чтобы десериализовать?)

Лично мне милы варианты 1 и 5. А вам?

«Спасибо за внимание, дети мои, с вами был я, Три-дог-найт, на волне вашего любимого Радио, Новости Галактики!» (С)

★★★★★

Ответ на: комментарий от Shadow
$ perl -e 'use strict; use JSON::XS; use Data::Dumper; print Dumper(JSON::XS->new->decode(qq|{"a": "b"}\n\n\x00 govno               |))'
$VAR1 = {
          'a' => 'b'
        };

Кстати, а mmap вполне себе вариант, коль скоро JSON::XS просто плюёт на мусор за границей закрывающей скобки!

DRVTiny ★★★★★ ()
Ответ на: комментарий от anonymous

Ну так давно известно, не 92, а все 95% людей - совершенно так себе :)

DRVTiny ★★★★★ ()

6) API для чтения структуры целиком + очередь на RabbitMQ

pru-mike ★★ ()
Ответ на: комментарий от anonymous

Полтора не получилось, но то, что ощутимо быстрее - факт. Но для меня осталось загадкой, как быть с разбухающими данными. В смысле, они-то могут хоть год не меняться почти в объёме, но потом вдруг скакануть в размере. Это может произойти в любой момент, а как с этим быть при фиксированном размере map'а?

DRVTiny ★★★★★ ()
Ответ на: комментарий от DRVTiny

Если настолько не предсказуемое поведение, то делать два mmap-файла - в одном хранить размер и адрес другого.

anonymous ()
Ответ на: комментарий от anonymous

Да, но Cache::FastMmap как-то справляется с изменением размеров хранимой структуры... Ну т.е. не создаёт несколько mmap'ов. В идеале я бы вообще использовал shmem ipc, но, как оказалось, оно работает как-то очень медленно, печально и нестабильно, хотя и непонятно, честно говоря, почему.

DRVTiny ★★★★★ ()
Последнее исправление: DRVTiny (всего исправлений: 1)
Ответ на: комментарий от DRVTiny

Cache::FastMmap как-то справляется с изменением размеров хранимой структуры

нет, perldoc Cache::FastMmap

One consequence of this is that you cannot store values larger than a page in the cache at all. Attempting to store values larger than a page size will fail (the set() function will return false).

shmem ipc

другой вариант: unix socket

anonymous ()
Ответ на: комментарий от anonymous

Кстати, да, я этот кусок текста прочитал несколько раз, а потом и другие куски текста на ту же тему, но я так и не понял, что вообще у него там за страницы такие. Я знаю страницы памяти страничной адресации, которые по-моему 4К, либо 4М в зависимости от значения одного бита в таблице страниц (huge page и обычная). Но что за страницы такие в Cache::FastMmap'е - непонятно.

На Unix socket'ах сделал «управляемый командами сервер», но что-то не не летает, потому и решил отказаться. Может, вернусь к сокетам, сделав протокол не универсальным, а то у меня он сейчас прямо под отладку через socat сделан, слишком «гуманный» интерфейс :)

DRVTiny ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.