4.2

Куча постов про bsd и т.п. уг, ни одного про отличия новой версии.

Вы это интаграмщикам расскажите.

То, что Wikipedia или морды Facebook сделаны на PHP, не означает, что этот язык предназначен для крупных проектов :)

2. Системы такого рода не предназначены для постоянного хранения данных.

Обоснуйте. И расскажите как же его тогда использовать? При запуске считал данные из мускула и сунул в Redis? На кой?

И тем не менее оно везде.

И расскажите как же его тогда использовать?

Для хранения key-value кешей.

При запуске считал данные из мускула и сунул в Redis? На кой?

Для хранения тех данных, извлечение которых из mysql слишком затратно и тяжеловесно. Ваш и.о. К.О.

И тем не менее оно везде.

Кто? PHP? Redis?

PHP конечно же. Куда ни плюнь, блин.

извлечение которых из mysql слишком затратно и тяжеловесно. Ваш и.о. К.О.

их можно один раз извлечь в RAM-таблицу, тут человек померял, что redis «всего» в 2-4 раза быстрее MySQL:

http://colinhowe.wordpress.com/2009/04/27/redis-vs-mysql/

если вместо InnoDB использовать HEAP - разницы может и не быть вообще

Разработка спонсируется компанией VMware.

Их же вроде Microsoft спонсировал, как и ноду? Или я опять часы не перевёл?

Я тут смотрел, как Докинз читает свои письма ненависти, так вот, вы мне на поминаете реакцией этих верующих

Блин. :)

Если Вам будет интересно, то это аналог уже существующего (и более простого) решения типа Oracle Embedded. Ранее — Berkeley DB от SleepyCat Software. Только там это сделано как набор библиотек, а здесь это... непойми что в общем.

Это не XML в чистом виде, хотя есть версия Berkeley DB XML для C++ и java. Скорее, это некое хранилище данных (свой формат), где значения упорядочены по их хешу. Вариантов индексирования четыре (я про BDB). Вариантов хранения так же несколько — в т.ч. и в ОЗУ (in-memory database). Есть поддержка транзакций и прочих пирогов и пряников, нужных для обеспечения целостности (в том числе).

По умолчанию это (я про Berkeley DB), как и писал выше — набор библиотек, так что там есть API, но нет SQL. Хотя, sqlite* это надстройка над именно Berkeley DB.

Авторы редиса явно любители ломиться в открытые двери. Для построения крайне быстрых No-SQL DB, работающих где угодно (хоть на встраиваемках), Berkeley DB подходит, но если нужно что-то с бриджем и поэтессами, то наверное это Редис, хотя я его и не использую.

Для скорости есть...

как уже писал чуть выше, Berkeley DB. А это непойми для чего.

Кстати, да! В дополнение к моему предыдущему постингу, могу заметить что в мускуле один из вариантов хранения БД это та же самая BDB. Какой именно — не помню, я им не пользуюсь. Возможно, что InnoDB. В букварях на мускуль это должно быть.

Если я не ошибаюсь, тот как раз у Redis было ооочень много проблем с производительностью, если все данные не влезали в память.

можно считать, что если он свопиться, то затупил

Собственно, для high-load мегатонны нужной/ненужной информации

каждый случай надо смотреть отдельно

То, что Wikipedia или морды Facebook сделаны на PHP, не означает, что этот язык предназначен для крупных проектов :)

redis вполне позицианируется как постоянное хранилище. Не вижу проблем с ним в этом.

При запуске считал данные из мускула и сунул в Redis? На кой?

Иногда это надо - он быстро отвечает. Иногда как постоянное хранилище. Каждый раз по разному. В этом его и прелесть.

Сколько подключений к базе было? Или кластер из баз городить?

редис не просто key->value

У redis есть журнал транзакций, так что гарантии не хуже чем у традиционной СУБД

как уже писал чуть выше, Berkeley DB. А это непойми для чего.

а как у нее с сетью? Я уж не говорю о таких приятных вещах, как set и order set

мускуле один из вариантов хранения БД это та же самая BDB

в новых версиях мускула bdb убрали

Их же вроде Microsoft спонсировал

Майкрософт спонсировал портирование на винду —да так, похоже, и не выспонсировал.

Я не юрист, но разве бремя доказательств не лежит на обвинителе? Учитывая, что пункта «обязан доказать» в договоре не помню.

Я тоже не юрист. Но, если программа достаточно старая и написана плохо, то есть шанс, что современный компилятор ее соберет «неправильно». Тогда я (как недобросовестный обвинитель) могу попробовать сфабриковать вот такое в качестве «доказательства» несоответствия, и бремя опровержения будет лежать, как я понимаю, уже на обвиняемом:

1. Скомпилировать код современным компилятором с -Wall -Wextra и без -Werror. Если не скомпилировалось - «а что, собственно, вы даете в качестве исходников?»

2. Прочитать все warning'и от шага 1. Найти что-нибудь про strict aliasing или другое неопределенное поведение. Посмотреть по коду, а есть ли от этого видимое изменение в поведении программы. Если есть - «ваш бинарник ведет себя не так, как мой бинарник, скомпилированный из ваших исходников, вот тест».

Естественно, про warning'и не говорить - пусть сами догадываются.

P.S. пример, где теоретически можно было провернуть такое: http://bugs.debian.org/295832

там филосифия иная: http://blog.getspool.com/2011/11/29/fast-easy-realtime-metrics-using-redis-bi...

Сенкюверимач.

С сетью у BDB ни как ровным счетом. С lua то же ни как. Set и order set безусловно удобны. Но они могут быть реализованы на уровне конкретного приложения программистом, как и «сеть» и поддержка lua. По сути дела, с задачей крайне быстрого доступа к данным BDB справляется. А большего от нее и не нужно. :)

Да. Это его и губит. Просто не понятно что это и зачем это. С BDB ответ куда как проще — это просто библиотеки. Не более.

Хмм. Не знал. Спасибо.

Тююю... Танимазащооо... :)))

То есть вы предлагаете на bdb написать свою штуку, к которой будет конектиться десятки сереров

Это делает его удобным инструментом.

redis это не просто хранилище, по сохраненным данным можно производить операции. например для множеств пересечение, объединение и т.д. и самое главное быстро и не затратно по ресурсам.

пересечение 1млн на 1млн около ~200мс это если использовать множества. а если использовать битовые массивы и AND OR XOR, то вообще моментально.

любому серверному приложению такие операции полезны, как с переносимостью так и без.

lua это еще один плюс и самая главная фича теперь.

Давно интересует подобное хранилище, но с одним дополнительным моментом — всё, сохраняемое на диск, должно быть зашифровано каким-либо образом.

PHP конечно же. Куда ни плюнь, блин.

Да, но это не делает его целью создание больших сайтов :)

Почти так.

На самой по себе BDB мне вряд ли удастся написать что-то подобное. Просто по факту того, что BDB это просто библиотеки, позволяющие организовать упорядоченное хранение данных и крайне быстрый доступ к ним на любом устройстве, где может работать (например) С код или python и не более. В виде sqlite3 это работает на той же nokia n900, в виде простого использования данной библиотеки это используется в системе (опять-таки например), разработкой которой я занимался не столь давно и которая работает вовсе не на нокии, и совсем не на нокии. :)))

Дело в том, что в описанном Вами случае, мне придется написать сервер (redis, по сути дела таковым и является), который будет реализовывать то, что написано в ТЗ. Например, мне нужен сервер сбора данных. Какова будет масштабируемость? Да такова, какая нужна мне в данном случае. Такой сервер может реализовать произвольное число подключение серверов/клиентов. Это определяется моим сервером и системой. Тем, насколько они оптимальны или не оптимальны.

С другой стороны, если мы посмотрим на http://redis.io/topics/benchmarks , то увидим красивую статистику. Все отлично. Но я повторю — это статистика для самого по себе сервера redis. В моем случае он на фиг не нужен ибо просто ни как не укладывается в рамки технического задания. И в моем случае (весьма вероятно) статистика могла бы быть не менее красивой, если бы она кому-то была нужна и ее кто-то снимал. Дело в том, что для передачи команд моему серверу мне не нужны IPC. Все решается намного проще — «сервер» (точнее, их несколько, но не в том суть) просто обменивается данными, которые хранит в BDB. Думаю, статистика будет даже... красиффше. :)))

Наконец, что касается обработки данных. Великолепно что пересечения находятся в доли секунды. Но тут вопрос — а на чем они находятся, в каком коде? В коде сервера? Великолепно! Но что если мне нужно поискать их на питоне? Или перле? Или, простите за немодность, в коде на С? Не знаю что там с редисом, с BDB нужно просто подстегнуть либу и спокойно произвести нужные операции. Они будут крайне быстры. ;)

Что касается шифрования данных. В случае с BDB можно либо хранить данные на шифрованном разделе, либо шифровать/дешифровать данные «на лету», в своем коде. Но во втором случае возникает вопрос что делать с хешами. Если они от шифрованных данных, то нельзя ли по ним будет полностью или частично восстановить данные? Да и искать будет что-то несколько затруднительно. Если от незашифрованных данных, то здесь опять есть возможность восстановить данные (если знать как именно формируется хеш). В общем, сделать такое можно, но подумать нужно.

Не нужно переходить на личности

Что касается шифрования данных. В случае с BDB можно либо хранить данные на шифрованном разделе, либо шифровать/дешифровать данные «на лету», в своем коде. Но во втором случае возникает вопрос что делать с хешами. Если они от шифрованных данных, то нельзя ли по ним будет полностью или частично восстановить данные?

https://github.com/antirez/redis/blob/unstable/src/rdb.c#L601

Зачем писать велосипед, если все есть. Да и не факт, что ты учтешь столько мелочей, сколько учтено в редисе.

И да и нет.

С одной стороны, да это велосипед. С другой стороны, этим велосипедом я решаю вовсе не сферическую задачу в вакууме, а вполне конкретную, изложенную в ТЗ. Я и не пытаюсь позиционировать это решение как одно на всех и для всех случаев жизни. Кстати, аналогичное по нагрузке решение видел. Продукт Wialon. Компания Gurtam (http://gurtam.com) заявляет о порядка 140000 объектов, которые сливают на их сервера информацию о состоянии/местоположении. Хранилище данных сделано как-раз на BDB.

Мне кажется, хотя я могу и ошибаться, что BDB как-раз для таких случаев.

можно либо хранить данные на шифрованном разделе, либо шифровать/дешифровать данные «на лету», в своем коде

Шифрованный раздел доступен другим программам, что работают в этот же момент времени. Шифрование на лету представляется мне велосипедом, в котором много гитик, изобретать его самому вопросительное занятие.

Спасибо. Посмотрел.

Не прельстило. Во-первых, не особо люблю camelStyle. Во-вторых, вынужден признать что мне удалось изысканно затормозить. :))) В случае с BDB, при создании базы, я должен указать флаг DB_ENCRYPT. Сконфигурировать используемый алгоритм я могу через DB_ENV->set_encrypt или через DB->set_encrypt. Там используется Rijndael/AES с длиной ключа в 128 бит и алгоритм SHA1 с 160 бит для контртольных сумм. Этого достаточно для того, чтобы данные либы применялись в госучреждениях Пендосстана. Правда, все что касается шифрации здесь, справедливо только для хранения данных, причем не важно говорим мы об in-memory database или об обычной, на диске. О безопасности представления данных в памяти программист должен заботиться самостоятельно.

В принципе, этого достаточно для повседневного использования, хотя лично мне это и без надобности.

Проблема решается проще.

Я выше отписался. Прошу прощения, но я просто забыл об этом варианте использования, т.к. мне он не нужен. С другой стороны, полной безопасности тут добиться в любом случае сложно, т.к. области памяти, где расположены критически важные данные также могут быть доступны другим программам, но это уже выходит за пределы обсуждения в части именно хранения данных.

области памяти, где расположены критически важные данные также могут быть доступны другим программам

Да, верно, ещё бывает ptrace и прочее, но это требует уже весьма заметных навыков у взломщика, что в наше время скрипт-киддис, всё-таки, редкость.

И да и нет.

Уповать на то, что скриптодетишки повально лазят, я бы не стал. Я еще помню те времена, когда DoS/DDoS считались не «атакой» как сейчас, а просто хулиганством. С другой стороны, я не могу исключить того, что из моего поколения не осталось ни кого, кто не могбы провести грамотную атаку. Скорее всего, наверное, просто перестали подписываться, звонить на всех углах об этом и... одели костюмы. ;) Но люди со временем слабо меняются. Снилось мне что если уж... «интересовался» этим когда-то, то, скорее всего, так и будешь этим... «интересоваться». Ну не всем же в продаваторы природных ресурсов подаваться. :))) Хотя это всего лишь мои домыслы и догадки и не более.

Я же не сказал, что это невозможно. Возможно, к примеру, запустить программу в виртуалке и снимать дампы памяти без вопросов. Моя затея не в том, чтобы защититься от владельца программы, а в том, чтобы случайный вирус, червь и пр пошли лесом.

Да. Я понял.

Видимо, в Вашем случае подойдет что одно решение, что другое. Правда, в моем случае, мне пришлось бы «покрутить в руках» редис и посмотреть на существующие там механизмы шифрации. Пока я этого не сделал, ни чего комментировать не буду, т.к. мои комментарии в таком случае не будут соответствовать истине.

Мне кажется, хотя я могу и ошибаться, что BDB как-раз для таких случаев.

Если key-value --- то да, сделайешь

А если сложнее - то надо писать. И, скорей всего, стоимость работы программиста будет больше, чем стоимость железо. Почти всегда так в низкоуровневом коде.

Писать надо, это да.

Но мы вообще-то выбрали профессию программистов (или она нас, не знаю).

С другой стороны, если данные есть, то над ними можно произвести любые манипуляции, которые хочет видеть заказчик. Самое главное в том, что это можно сделать крайне быстро, без каких-то диких напрягов по железу. С железом и сравнением с з/п все то же не так очевидно. Как правило, такого рода проекты пишутся не на один год использования. Мне доводилось видеть (сейчас вот переписываю проект), где использовалась BDB версии еще 2.0. Последняя правка кода (судя по коду) относится к 1999г. И он вполне работоспособен. И им, самое смешное, вовсю пользуются, даже не зная о нем. :))) Вот уже сколько лет. И многократно отбил затраты на з/п тех программистов, которые его создали изначально. Переписка нужна чисто косметическая — прошерстить на предмет багов в сетевом протоколе (то, что нет эксплоитов вовсе не означает того, что там все ровно), ну и запуск через xinetd в наши времена выглядит диковато (ЕМНИП, родоначальники этого супер-демона из редхат от него в 1998г. сами отказались). Ну и еще по мелочи чего, например, в API Linux появилось некоторое число вкусных плюшек, которых в те времена просто не было и код можно сделать более быстрым. Низкоуровневый код это не всегда зло. Как правило, это решение типа «выстрелил и забыл». Поставил и пусть его живет. В логи иной раз только поглядывай. Так, на всякий случай. :)

Добавьте сюда скорость разработке. Особенно, если хотелки заказчика, которые он захочет завтра, должны были быть сделаны вчера.

Ну, мне проще несколько.

Я понимаю что это стандартная ситуация, но я так же отдаю себе отчёт в том, что есть Т.З. и оно подписано и заказчиком и нами. Все остальное, осенившее заказчика буквально вчера, что он возжелал сформулировать сегодня, идет как дополнение к Т.З., за отдельные деньги. Да. Мне приходится писать. Но делаю это я за деньги.