Комментарии 44
А как же редис?
А как же in memory mnesia? Тоже встроенное средство, и возможность создавать кластеры присутствует.
Автор, может выложите код бенчмарков, чтобы можно было воспроизвести самостоятельно? Глянул я на драйвер memcached, который вы использовали — захотел расчехлить профайлер. Сдается мне, что скорость, которую показывает драйвер, можно улучшить.
И да, было бы полезно указать размер сообщений, которые Вы загоняете в хранилище. И зависимость вида «размер сообщения -> скорость вставки (байт в секунду)». Такая зависимость позволит вскрыть проблемы в реализации сетевого взаимодействия со стороны erlang-клиента. Я часто натыкался в библиотеках на косяки, просаживающие производительность tcp на отправке множества мелких пакетов.
Понятно, что общей картины это не изменит, но все же интересно было бы поглядеть.
Понятно, что общей картины это не изменит, но все же интересно было бы поглядеть.
Про гипотетические потери данных ets при падении owner process.
ets:new(name, [{heir, Pid, heirdata}])
И да, покажите как у вас делаются выборки, там для ets есть нюансы.
ets:new(name, [{heir, Pid, heirdata}])
{heir,Pid,HeirData} | {heir,none}
Set a process as heir. The heir will inherit the table if the owner terminates. The message {'ETS-TRANSFER',tid(),FromPid,HeirData} will be sent to the heir when that happens. The heir must be a local process. Default heir is none, which will destroy the table when the owner terminates.
И да, покажите как у вас делаются выборки, там для ets есть нюансы.
Ну, потери данных вполне себе не гипотетические. Как вас heir спасет например от краша ноды? Или от одновременного краша обоих процессов?
Краш ноды — принимается, от него чистым ets никак не спастись.
А вот heir будет работать ровно так, как вы его напишете. И если он не должен падать, он не будет падать, только и всего.
А вот heir будет работать ровно так, как вы его напишете. И если он не должен падать, он не будет падать, только и всего.
Согласен. Но как по мне — это все какие-то неоправданные сложности. Подхода (настоящих) я вижу только два (может я ошибаюсь — тогда буду благодарен, если меня поправят).
1. Данные не жалко потерять (данные представляют собой просто разогретый кэш).
2. Данные критичны. Тогда тот, кто пишет, должен быть уверен, что уровень хранения либо пришлет асинхронное подтверждение на каждую попытку записи, либо проведет запись синхронно, гарантируя, что данные (к тому моменту, как выполнение «писателя» продолжится) уже стопроцентно и полностью записаны на диск (и ничего там не поломали).
Heir с этой точки зрения выглядит как некая полумера. Он хорош в том случае, когда нужно обработать падения owner'а так, чтобы система не пришла в неконсистентное состояние. И, честно говоря, видел очень мало действительно адекватных применений heir.
1. Данные не жалко потерять (данные представляют собой просто разогретый кэш).
2. Данные критичны. Тогда тот, кто пишет, должен быть уверен, что уровень хранения либо пришлет асинхронное подтверждение на каждую попытку записи, либо проведет запись синхронно, гарантируя, что данные (к тому моменту, как выполнение «писателя» продолжится) уже стопроцентно и полностью записаны на диск (и ничего там не поломали).
Heir с этой точки зрения выглядит как некая полумера. Он хорош в том случае, когда нужно обработать падения owner'а так, чтобы система не пришла в неконсистентное состояние. И, честно говоря, видел очень мало действительно адекватных применений heir.
Что ж оно все такое медленное… можно на memory-mapped файлах сделать хранилище (то есть персистентное), которое будет держать миллионы запросов в секунду.
LMDB например по-фичастости обходит много кого. По-размеру базы тоже много кого, даже при использовании snappy.
Сделать можно, разумеется. Но смотрите:
Т.е., задача решается штатными средствами в три строчки. А сколько времени будет потрачено чтобы сделать что-то на memory-mapped файлах со свойствами более или менее приближающимися в коробочному функционалу?
На самом деле, более корректным было бы сравнение dets например с вот этим github.com/basho/eleveldb/. Или даже с вот этим github.com/norton/lets/. Только вот задача «хранить данные» не такая уж типовая для эрланга. Редко оно бывает нужно.
1> {ok, _} = dets:open_file(table, [{file, "/tmp/my.dets"}]).
{ok, table}
2> dets:insert(table, [{foo, bar}, {bar, baz}]).
ok
3> dets:lookup(table, bar).
[{bar,baz}]
Т.е., задача решается штатными средствами в три строчки. А сколько времени будет потрачено чтобы сделать что-то на memory-mapped файлах со свойствами более или менее приближающимися в коробочному функционалу?
На самом деле, более корректным было бы сравнение dets например с вот этим github.com/basho/eleveldb/. Или даже с вот этим github.com/norton/lets/. Только вот задача «хранить данные» не такая уж типовая для эрланга. Редко оно бывает нужно.
Я мимо проходил. Я только начал использовать э-г, как раз застрял на «хранить данные».
Так вопрос был в том, почему нельзя было это реализовать внутри штатных средств. Даже если все делать очень-очень обобщенно, чтобы оно переваривало любые данные без всякой конфигурации, оно должно было получиться в разы быстрее.
memory-mapped это очень медленно и плохо, потому что непредсказуемо по скорости доступа.
У монги в принципе плохая архитектура, которую не исправить.
У монги в принципе плохая архитектура, которую не исправить.
Почему memory-mapped это очень медленно и плохо? В худшем случае, будет 1 чтение с диска, в уникально плохом случае — два, не больше. File-based хранилища ходят на диск по каждому запросу, и ничего.
потому что непредсказуемо. Хранилища с файловым бекендом точно знают, когда пойдут на диск за данными, а монго нет.
А что, в Монге memory-mapped? Не знал. В любом случае, не ее имел ввиду, а абстрактно.
Memory-mapped хранилище может пойти на диск, причем, скорее всего, не пойдет. Disk-backed пойдет точно. Причем сравнивать вполне корректно между собой, если вы не закладываетесь на внезапное выключение сервера.
Это все равно, что сказать: плохая непредсказуемость, могу 10 рублей в день заработать, а могу 100. Вот строго по 10 рублей в день лучше, стабильность, красота.
Memory-mapped хранилище может пойти на диск, причем, скорее всего, не пойдет. Disk-backed пойдет точно. Причем сравнивать вполне корректно между собой, если вы не закладываетесь на внезапное выключение сервера.
Это все равно, что сказать: плохая непредсказуемость, могу 10 рублей в день заработать, а могу 100. Вот строго по 10 рублей в день лучше, стабильность, красота.
нет, неверно.
disk-based базы данных используют память, которая им выделена и обслуживают из памяти если могут. Если не могут, то предсказуемо идут на диск.
К монге один и тот же запрос два раза подряд может обслужиться то из памяти, то не из памяти.
Скорость без предсказуемости — это суходрочка на бечмарки.
disk-based базы данных используют память, которая им выделена и обслуживают из памяти если могут. Если не могут, то предсказуемо идут на диск.
К монге один и тот же запрос два раза подряд может обслужиться то из памяти, то не из памяти.
Скорость без предсказуемости — это суходрочка на бечмарки.
Что могут держать disk-based хранилища в памяти? Пускай некий кеш, чтобы за самыми ходовыми ключами на диск не лезть. Ну так memory-mapped делает то же самое органически, потому что популярные страницы никогда не будут вытеснены на диск (в ядре наверняка для mmap какой-нибудь псевдо-LRU есть).
Вы постоянно упускаете из виду вопрос с предсказуемостью скорости доступа к данным.
disk-based точно знает, когда пойдет на диск. Монга не знает, поэтому в случае роста нагрузки монга начинает неконтролируемо захлебываться.
disk-based точно знает, когда пойдет на диск. Монга не знает, поэтому в случае роста нагрузки монга начинает неконтролируемо захлебываться.
Ок, disk-based что-то закешировал, и знает, за каким ключом пойдет на диск, а за каким не пойдет. Но оно же не знает, какой следующий ключ прилетит! Неопределенность заложена в типичном паттерне доступа.
Да что вы со своей Монгой, я вообще ее в глаза не видел никогда, но судя по тому, что она делает всего единицы тысяч запросов в секунду, при том, что mmaped, не представляю, что там за говнокод, либо совсем-совсем не для key-value паттерна не предназначена.
Наше mmaped key-value хранилище имеет среднее время доступа 200 (на маленьких размерах) ..1000 (если миллиард записей) наносекунд, worst case latencies там конечно похуже, но популярные ключи на это не напорятся, потому что страницы с ними операционная система не вытеснит. Это в разы быстрее, чем ETS, который вообще-то чисто in-memory. Пациент скорее жив, чем мертв.
Да что вы со своей Монгой, я вообще ее в глаза не видел никогда, но судя по тому, что она делает всего единицы тысяч запросов в секунду, при том, что mmaped, не представляю, что там за говнокод, либо совсем-совсем не для key-value паттерна не предназначена.
Наше mmaped key-value хранилище имеет среднее время доступа 200 (на маленьких размерах) ..1000 (если миллиард записей) наносекунд, worst case latencies там конечно похуже, но популярные ключи на это не напорятся, потому что страницы с ними операционная система не вытеснит. Это в разы быстрее, чем ETS, который вообще-то чисто in-memory. Пациент скорее жив, чем мертв.
ваше mmaped хранилище не может иметь среднее время 1000 наносекунд, потому что вы не знаете, когда прилетит запрос к той части данных, которые на диске.
Если вы так говорите, значит вы не начали пользоваться им в режиме, когда много дискового доступа.
Что же касается ets, то значит вы ещё не доросли до мультитредного доступа.
Короче, начнете пользоваться, поймете почему mmap не работает.
Если вы так говорите, значит вы не начали пользоваться им в режиме, когда много дискового доступа.
Что же касается ets, то значит вы ещё не доросли до мультитредного доступа.
Короче, начнете пользоваться, поймете почему mmap не работает.
ваше mmaped хранилище не может иметь среднее время 1000 наносекунд, потому что вы не знаете, когда прилетит запрос к той части данных, которые на диске.
Почему это вдруг не может?) Best case быстрее, worst case медленнее, среднее 1 us.
значит вы ещё не доросли до мультитредного доступа.
Есть lock striping на 8 тысяч локов (по умолчанию, можно сделать любой практически).
Короче, начнете пользоваться, поймете почему mmap не работает.\
Спасибо, пользуюсь, mmap работает.
Какой write concern вы использовали для Mongo? Без его конкретизации не понятны результаты.
> Название ОС: Windows 7 Professional
в принципе на этом можно заканчивать.
Ни одна из перечисленных вами программ вообще не планировалась к использованию под виндовс и рассчитаны на работу под линуксом.
в принципе на этом можно заканчивать.
Ни одна из перечисленных вами программ вообще не планировалась к использованию под виндовс и рассчитаны на работу под линуксом.
Ну почему заканчивать… разница между Виндой и Линуксом при тестировании хранилищ будет максимум десятки процентов. А разница между самими хранилищами — разы и даже порядки. Так что в целом результатам можно верить.
нет, не можно.
Монга работает на mmap, а разница между mmap и read/write под виндовс непредсказуемо другая по сравнению с линуксом.
Монга работает на mmap, а разница между mmap и read/write под виндовс непредсказуемо другая по сравнению с линуксом.
ну и плюс никто не оптимизирует подобный софт под виндовс. Разница может быть на порядки, потому что виндовс для всех — это «лишь бы запустилось у того парня на форуме». Тут и cygwin и прочие решения, дающие непредсказуемую просадку.
Это так же, как запускать MS SQL под wine (что, конечно, само по себе было бы достижение года)
Это так же, как запускать MS SQL под wine (что, конечно, само по себе было бы достижение года)
Я не спец в этом вопросе, но почему-то мне кажется, что в Винде mmap и производительность файлового доступа должна быть не хуже, чем в Линуксе. Ну, может, где-то чуть лучше, где-то чуть лучше, но в целом близко. Потому что иначе, я не понимаю, как вполне себе серверные решения типа MSSQL, .NET стек и т. д. на Винде в принципе крутятся, и это не детский сад.
серверные решения под винду делались под виндой теми средствами, которые есть под виндой и рассчитаны только под винду.
Вы же пытаетесь на чуждой и плохо пригодной для сервера платформе запустить софт, который делали люди, уже очень много лет не видевшие виндовс в глаза.
Вы же пытаетесь на чуждой и плохо пригодной для сервера платформе запустить софт, который делали люди, уже очень много лет не видевшие виндовс в глаза.
Как бы есть POSIX вызовы mmap, munmap, msync и т. д. Есть прямые аналоги на Винде. Судя по тому, что на Винде это используется в том числе их собственными серверными технологиями, и просто исходя из веры в то, что у разработчиков Винды тоже есть мозг и они могут писать эффективный код, я полагаю, что производительность виндовой реализации, по крайней мере, сопоставима с линуксовой.
«Расчет только на Винду» заключается в том, что там вызовы не mmap стоят, а местных функций, уж не знаю, как они называются. А не в том, что там вообще нет ничего подобного, и схожая функциональность достигается каким-то диким лапшекодом, криво реализующим то же самое в user mode/space, причем на порядок медленнее.
«Расчет только на Винду» заключается в том, что там вызовы не mmap стоят, а местных функций, уж не знаю, как они называются. А не в том, что там вообще нет ничего подобного, и схожая функциональность достигается каким-то диким лапшекодом, криво реализующим то же самое в user mode/space, причем на порядок медленнее.
1) Замеры делались с учетом того что хранилища работали на той же машине, правильно? А при реальном использовании вы тоже будите запускать все на одной машине? Просто практика показывает, если хранилище оказывается даже в одной локальной сетке, но на разных компах, скорость будет совсем другой, так основная задержка будет при передаче по сети.
2) У монги есть 3 официальных режима: write, write/2, write/3. Если будите делать ещё раз замеры, советую попробовать все три, дело в том что write самый медленный, но самый надежный. write/3 быстрее и почти так же надежен, а вот write/2 это практически in memory скорость, так как монга не будет ничего писать на диск, а сразу отдаст управление обратно. Минус — естественно, если монга упадет, вы об этом не узнаете, а просто потеряете данные, плюс есть шанс что при немедленном чтении, клиент не успеет увидеть последних изменений. Однако, как раз при таком режиме она может использоваться как быстрый кэш для не особо критичных данных (при этом это будет более надежно чистого in memory).
2) У монги есть 3 официальных режима: write, write/2, write/3. Если будите делать ещё раз замеры, советую попробовать все три, дело в том что write самый медленный, но самый надежный. write/3 быстрее и почти так же надежен, а вот write/2 это практически in memory скорость, так как монга не будет ничего писать на диск, а сразу отдаст управление обратно. Минус — естественно, если монга упадет, вы об этом не узнаете, а просто потеряете данные, плюс есть шанс что при немедленном чтении, клиент не успеет увидеть последних изменений. Однако, как раз при таком режиме она может использоваться как быстрый кэш для не особо критичных данных (при этом это будет более надежно чистого in memory).
Использование внутренних механизмов допустимо, а надёжность лучше обеспечивать в традициях OTP — через сегрегацию процессов (храните кэш в несколько слоёв из процессов). Хотя в таком случае выигрыш не факт, что окупит стоимость разработки.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сравнение скорости обработки данных (ETS, DETS, Memcached, MongoDb) в Erlang (сферическое в вакууме)