Pull to refresh

Comments 126

Заманчиво. Современным веб разработчикам думаю не хватает такой легковесненькой очень быстрой нереляционной БД. А может просто мозгов не хватает и все по старинке юзают MySQL.
Большинство начинающих веб-разработчиков, по моему наблюдению, не думают о производительности своего приложения. Вон сколько книг «PHP5+MySQL» продаётся. Таким образом начинающего программиста сразу приучают хранить все данные в MySQL.
В то же время, Redis достаточно, по крайней мере для 80% всех проектов.
Как ни крути, а большинство все таки пишет для площадок которые дают хостеры, либо необходимы унифицированные решения, что б опять же клиент мог повесить на каком почти бесплатном хосте, для людей которым производильность пофигу(как в прочем и сам сайт).
Как часто на хостах есть, что то кроме мускула(ну пусть постгре еще), в большинстве случаев стоит говорить спасибо уже за то чтоб сесию не в общий темп сваливали.
Это не книжки приучают, это рынок проводит селекцию.

ЗЫ: сейчас опять приходится писать унифицированную систему, с расчетом на такие древности которые лучше не поминать в суе:-(… И скучаю, по возможности попрерикаться с одмином, о том как сделать что б это все «летало»
ЗЫ2: жарко кондей не справляется, оптимизму чет совсем мало.
Хостеры могут сэкономить себе много сил, нервов и финансов, установив такую штуку как Reds и приучив к нему программистов.
Сейчас ресурсы хостингов расходуются пользователями уж очень не оптимально, но виноваты в этом скорее разработчики скриптов.
Если бы тот же (прости госпади) 1С Битрикс работал на Redis, то уверен, все хостинги мигом бы организовали бы у себя Redis-сервера.
И главное, что все бы выиграли: заказчики и конечные пользователи получили бы большую скорость работы сайта, хостинги получили бы снижение нагрузки на своё железо, а следовательно финансовую экономию.
Вопрос, а зачем? если и так все довольны.
Не устраивает, что стоит на сервере покупай вдс или дедик… вперед. И будет тебе и редиска и сосиска и что душе угодно.

Оно ни кому не надо(вру, есть те кому надо и это вселяет надежду), именно потому слишком часто приходится слышать пхп=говно. ИМХО пхп != говно, но нормально им пользуется не так много человек. Большинство для того что б написать говно-код, потому как сайт надо сдать вчера, а книжку по пыху купил только сегодня.
Отсутсвие зрелых инструментов и постоянная необходимость поддердивать подобные чудо-творения, наводят все большее желание перейти куда нить на яву или питон:-(… хотя хорошо, там где нас нет
UFO just landed and posted this here
Есть Google App Engine :) с их БД. Если бы у меня не было своего дедика, то я бы писал проекты под него)
80% проектов не требуется реляционная модель данных?
мне кажется, Вы преувеличиваете.
Возможно вы правы, но по моему скромному мнению, доля таких проектов существенна.
сама структура сайта подразумавает реляционность. чтобы ее реализовать, придется либо велосипедить в коде программы, либо выносить взаимоотношения данных в отдельное хранилище (xml, например), что не есть правильный путь, по-моему.

вообще, я согласен с этим комментарием. сравнение redis с БД не совсем уместное, по-моему.

даже если в данный конкретный момент можно ограничиться redis-ом, при развитии проекта начнутся сложности, которые рано или поздно приведут к реляционной модели данных.
Согласен, велосипеды — плохо. Можно связи и информацию для сложных выборок хранить в MySQL, а простые данные — в Redis.
Я не столько призываю заменить MySQL Redis'ом, сколько хочу обратить внимание на быстрые и простые хранилища для тех данных, которым не требуется реляционность.
структура сайта подразумевает реляционность? Окститесь. Чего-чего, а реляционности там кот наплакал.
начинающие веб-разработчики по природе своей не должны задумываться о производительности — у них и других проблем хватает. Например: изучение собственно предметной области. А вот оптимизация и прочие хайлоады — это уже удел совсем не начинающих.
т.е. кто-то не согласен, что сначала веб-разработчик должен научиться программировать, а потом уже заниматься performance optimization? ;-) хехе…
performance optimization должна быть по ходу написания и проектирования проекта, а не тогда когда уже «совсем туго стало»
или я неверно выразился, или вы меня неправильно поняли. попробую расшифровать свой коммент:
оригинал coolspot:
Большинство начинающих веб-разработчиков, по моему наблюдению, не думают о производительности своего приложения.


ну так вот, повторюсь: начинающим разработчикам следует сосредоточиться на умении писать гибкий и поддерживаемый код. А умение оптимизировать и писать код под нагрузки — это задача для более опытных коллег. Согласны? :-)
нет конечно :)
Оптимизация это же не какая то страшная тайна в которою просвещают только избранных, конечно же, согласен, что эти знания приходят в основном с опытом. Но если человек учится писать гибкий и красивый код, так почему он должен опускать оптимизационные моменты, зачем ?, чтобы потом переделывать «правильно»?

например взять mySQL ?, некоторые люди умудряются завалит весь сайт одним запросом, а все из за того что он пропустил раздел где рассказывали например о индексах, или сортировке данных, зачем он их пропустил? да потому что ему сказали что он начинающий программист, и ему ненужно читать об оптимизации :)
оригинал beat:
нет конечно :)
Но если человек учится писать гибкий и красивый код, так почему он должен опускать оптимизационные моменты, зачем ?


не хотелось бы разводить холивары, но не ответить не могу: гибкий, качественно написанный код оптимизировать проще. т.е. сначала пишем хорошо, потом смотрим, что тормозит, потом оптимизируем то, что тормозит. как-то так.

оригинал beat:
например взять mySQL ?, некоторые люди умудряются завалит весь сайт одним запросом, а все из за того что он пропустил раздел где рассказывали например о индексах, или сортировке данных, зачем он их пропустил? да потому что ему сказали что он начинающий программист, и ему ненужно читать об оптимизации :)

а это и есть опыт :-)))
ну вот Вы пишете:
«сначала пишем хорошо»
потом
«потом смотрим, что тормозит»

если оно тормозит то значить уже не «пишем хорошо» :)

ладно, не будем холиварить, так как и у Ваших и у моих словах есть часть своей правды, и отправим наш треп в null :)
Да, но всё же многим начинающим разработчикам большие реляционные возможности MySQL совсем не нужны. Они очень часто используют реляционную БД для хранения плоских данных ключ-значение.
Возможно по поводу 80% я преувеличил, но согласитесь, большое количество задач не требует реляционной модели данных.
мммм… хз, я не в состоянии оценить долю рсубд и не-рсубд в текущей массе приложений.
Интересно что же подразумевается вами под «80% всех проектов» в интернете. В эти 80% «интернет магазин» попадает по-вашему?

По моему нереляционная модель БД может использоваться только для кеширования.
Ну и конечно же можно использовать на сайта-штамповках, все данные для которых можно сохранить даже под одним ключом в нереляциоонной БД. я надеюсь вы не относите сайты-штамповки к определению «проект»
почему тогда всем монстры используют их «не только для кеширования»? Гугл, линкедин, фейсбук, амазон и другие…
хм. ну да, конечно же нереляционная модель удобна там где намного удобнее лишь хранить данные как ключ-значение.
но, мы же не забываем что «Гугл, линкедин, фейсбук, амазон и другие… » используют нереляционную БД как дополнительную к реляционной-основной? Ими нереляционная модель БД в основном используется для кеширования
где написано, что именно для кеширования? а тот же Map/Reduce или BigTable — это что, кеширование? Испрльзуется и для обработки, там, где важна скорость и суперважно масштабирование, при этом сложных выборок или запросов нет.
а кто вам мешает эти связи реализовать в key/value стораджах?
comments:$user_id
comment:id
comment:id
comment:id

и

comment:$id
comment:date
comment:body

?
и на выходе 2 быстрых запроса к стораджу, а не сиквельный join.
ну допустим нужно получить список последний 10 продуктов. тогда мне нужно использовать дату как ключ иначе мне придется выдернуть все продукты и проверить дату.

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

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

10 последних беретё следующий инкримент из продуктов и беретё 10 предидущих.
1-2 храним список продуктов под одним ключом и добавляем туда ид по мере поступления, а сами продукты каждый под своим.

В общем, посмотрите хотя бы тот же пример твиттерклона в примерах.
Не путайте теплое с мягким. У БД и кеширующего хранилища достаточно разные задачи и области применимости. Если не требовать от БД Atomicy, Consistency, Integrity, Durability, реляционности и поддержки SQL (читай, концепции связанных таблиц и инструмента для оперирования данными), то она будет летать.
Я особо и не путаю. Просто большинству сайтов не нужны эти фишки, вплодь до того что реляционность даже не нужна многим. Контент обычно слабосвязан.
Контент обычно слабосвязан.

Да бросьте Вы. Приведите пример сайта, где контент слабо связан.
Любой бложек. А облако тегов можно реализовать за счет таблиц ссылкок.
а комментарии? а авторы?
это все слабо связанный контент чтоли?
Слабо, не значит не связанный. Скажем так, тот набор операций над данными который предусмотрен в СУБД MySQL в большинстве веб задачек получается избыточным. авторы, комментарии и прочее вполне можно реализовать с помощью словарей а потом делать мультигеты по ключам.
БОльшая часть контента сайтов и порталов это кешированный контент, для хранения которого используется или следует использовать key/value, это во-первых.

И даже сам URL этой страницы — является по сути своей ключом.

В случае с реляционной моделью, запрос включал бы выборку страницы по id и выборку комментариев, parent_id у которых был бы равен этому id.

В нереляционной модели, эта страница хранится, как единственный объект (документ) в хранилище и при добавлении комментария обновляется.

Вместо такой лаконичности, мы должны иметь 2-3 таблицы, которые связаны через некоторое поле.

Не кажется хаком? Особенно при условии, что иерархия комментариев всё равно существует лишь на программном слое, потому что хранить ветки комментариев в виде некой структурой с реляциями это безумие.

В любом случае в key/value можно эмулировать связи там, где они нужны.
у меня есть также класс, работающий с несколькими серверами, и другие плюшки вроде сериализации. code.google.com/p/redis-ajax-chat/source/browse/trunk/lib/Redis_Server.php однако это устаревшая уже версия, новую на днях выложу и буду работать над полной поддержкой 1.0 версии.

эх, опередили меня с статьей о редисе, но ничего :)
Видел ваше имя на оф.сайте Redis =)

A new PHP programming example with Redis! In the form of an Ajax chat, released as open source, download and demo here, thanks to Александр Лозовюк.


Бросается в глаза =)
да, это было знакомство с проектом. еще я одно время вел проект по поддержке порта под Win32 через Cygwin, правда последние версии еще не собираются.
Обновил топик — упомянул IMemcacheClient
Отлично, push/pop это как раз то, чего не хватает в memcached! Присмотрюсь, т.к. memcached использую в полную катушку.

Вопрос только, что за backend хранит данные на диске? Или у вас свой собственный формат хранения данных?
А вообще есть опыт использования этой штуки в действительно большой проекте? Я работаю над социальной сеткой с весьма богатым функционалом, там хранится не только данные будут, но и очень много всяких флагов на сессию, т.е. должен быть так же expire time. А использовать сразу два хранилища весьма накладно по железкам будет.
требует много памяти. однако работает шустро, а специальные типы данных очень упрощают жизнь и архитектуру. Используем в крупном проекте приближенном к реалтайму.
А оптимизацию потребления памяти планируете делать? :)
сжатие (уже реализовано в начальном варианте), однако память расходуется в зависимости от хранимых данных — то есть если их много (и ключи длинные), то она расходуется.
UFO just landed and posted this here
где-то в рассылке по редису (гугл-група) было сообщение от автора о расчете сколько надо памяти в зависимости от длины ключа и данных. я покопаюсь на досуге
UFO just landed and posted this here
а вы посмотрите в примерах — там упрощённый твиттер-клон на пхп под редис.
недавно для в одном проекте попробовали в качестве хранилища для юзер ивент лога, пока очень довольны.
кстати redis manager никто не запускал? а то что то не получается пока что.
ну это немного не то, это документ-ориентированная база, но разработка, без сомнения, интересная
Какого размера может быть база? Возможно ли динамическое создание баз и их одновременное использование? Как сказывается размер базы на быстродействии?
какого нужно. да возможно, практически не сказывается, потому как постоянно данные в оперативке, и в зависимости от ваших настроек время от времени сохраняется на жёсткий диск.
Но ведь оперативки гораздо меньше, чем диска. Наверное все же хранится лишь актуальная часть данных там?
Хранятся все данные. Если во время работы данных становится больше, чем оперативной памяти, то используются возможности ОС — swap.
Таким образом, после перезагрузки и очистки swap, данные не уместившиеся в RAM будут утеряны.
Ответы об этом в FAQ проекта.
Хорошо подругому задам вопрос. Вот у меня есть машина с 2 гигабайтами памяти, что будет если база 6 гиг?
это же серверное решение, к тому же распределенное. сервера бывают и с 32 Гб памяти и больше…
это же серверное решение, к тому же распределенное. сервера бывают и с 32 Гб памяти и больше…

Типа дабавляйте память до упора? Оно как-то вообще уведомляет что у нас скоро кончится память и надо что-то делать или как? Просто мне не шибко нравится ситуация когда я добавляю в базу данные, а она внезапно падает.
2 Гига будет в RAM, 4 Гига в swap.
Работать Redis будет непредсказуемо то быстро, то медленно, в зависимости от того, где находятся запрашиваемые данные, в swap или в RAM.
Во время работы Redis, согласно своей архитектуре, будет скидывать данные из RAM (swap) на жёсткий диск, что иногда будет приводить к абсурдному копированию с диска на диск (из swap в файл-хранилище).
Освещение этого вопроса в FAQ проекта.
А размер базы задать жестко можно? Чтоб оно ругалось что мем закончился сделайте ченить.
Пока такая штука только в планах разработчиков. Сейчас узнать, что память кончилась и в ход пошёл swap можно только по начавшимся тормозам.
Авторы рекомендуют использовать уже существующую команду INFO для получения количества израсходованной памяти, для своевременного увеличения её объёма. =)
ну в принципе, это можно закодировать в клиент. Если есть запрос со стороны сообщества, в своем классе на РНР я бы мог такое сделать (правда, некоторой ценой потери скорости работы, но увы).
сейчас поддерживается до 16 баз, да, можно параллельно хоть все использовать (удобнее, если клиент поддерживает это, иначе вручную переключаться надо будет в запросах). Размер, в принципе, влияет на скорость сохранения, однако, это сложный вопрос (запись асинхронная, и если за промежуток от первого сохранения не добавлено пару гиг, то не сказывается, однако это настраиваемо вполне). Влиять будет подьем базы с дисковой копии при рестарте сервера.
У меня просто есть мысль использовать такого рода базу для хранения ключ-данные, где ключ это id + timestamp. Ну и что не мало важно данные могут требоваться переодически. Есть небольшой набор оперативных данных и большой набор не оперативных данных (к примеру по дням). До Redis я хотел посмотреть berkley db 4.
да, вполне, я так делал для чата. можно еще организовать в списки или скомбинировать. вполне рабочий вариант.
У меня не чат, у меня сервер мониторинга. Просто есть мысль брать оперативные данные и более старые данные из сегментов. Я вот начинаю подозревать, что если для оперативных данных redis подойдет, то вот для не оперативных как-то будет не очень.
важно, что принцип ключей по таймстампу работает, можно еще группировать по временным отрезкам и хранить списки (например, список на каждый отрезок времени минутный).

Да, как прокси-кеш он отлично работает. В аналогичном сервере мониторинга логов работает (на сайте есть новость про использование в каком-то сервисе, мы также думаем вот сделать адаптер для Zend_Log чтобы туба писать логи, а сервер статистики будет забирать периодически данные и записывать уже для долгосрочного анализа.
тогда уж лучше группировать по ID и хранить списки временных отрезков за час к примеру (60 значений в списке при одной проверке в минуту), ну и для использования работы поверх большого набора оперативных данных использовать точно лучше не надо.
Для не оперативных лучше MemcacheDB.
А он поддерживает конкурентный доступ?
По крайней мере атомарные операции инкремента/декремента поддерживает. Или что Вы имели ввиду?
в редисе вроде все операции атомарны, и декремент/инкремент также есть, кроме того все операции имеют прогнозированный уровень сложности
Мы о MemcacheDB. В редисе намного больше атомарных операций, но он не подходит для хранения объёмов данных, превышающих RAM, поэтому речь зашла о MemcacheDB (который кладёт в память только часто используемые данные) и его атомарных операциях.
Я имел ввиду, что если суммарный размер данных превышает размер оперативной памяти, то Redis будет фигово работать: во время запуска он будет загружать данные из файла-хранилища в оперативку, если в RAM не влезет — он пойдёт во все тяжкие в swap и так пока все данные не окажутся в виртуальной памяти.
MemcacheDB же загрузит в оперативную память столько, сколько указано в конфиге, а остальное оставит лежать на диске. Если к каким-то данным будут обращаться чаще других — он их положит в RAM надолго.
Да не пожалуй все же надо брать berkley db для архивных данных и не выеживаться ;)
Классная штука. Memcache проигрывает.
это немножко разные вещи, коректнее было бы сравнивать с memcacheDB.
Интересно, что бы вы сделали, если бы fruitbooter был против? :) Комментарии ведь нельзя удалять.
Я тоже об этом подумал, хитро улыбаясь =)
Но у меня есть отмазка: Я бы закрыл публичный доступ к Google Docs — документу, частью которого являются графики.
PHP, установленный на Windows, может обращаться к Redis-серверу установленному на *nix пр помощи TCP/IP =)
Redis — сервера для Windows, пока, нет.
Был пьян, неправ, вспылил… =)
Круто, дома сравню memcache, mysql и tokyo
З.Ы. Извините, а что за тег «плохой человек»? :)
«Редиска — нехороший человек», исправил тег =)
Интересно, как с производительностью относительно MangoDB? Пользуюсь ей, очень рад пока.
может вы имели ввиду MongoDB, от Стартапа 10gen, которые делали интересную платформу для клоуда, а потом переключились на ее основной компонент — базу
Да, заработался видимо :) Конечно Mongo :)
Кстати, интересная штука. Тем, кому интересно — www.mongodb.org/display/DOCS/Home

А вы могли бы написать пост о ней? как практик, а то я собираюсь также, но больше в теории. И скажите еще, плиз, с ней можно работать с РНР без расширения, через сокеты например? Иначе это существенное ограничение (для меня, как минимум).
Через сокеты, честно говоря, пока не пробовал :) Пост написать — действительно идея неплохая, надо будет заняться :)
Ссылка на IMemcacheClient есть в посте.
Тогда достаю уже использованный шаблон:
Был пьян, неправ, вспылил… =)
Вобщем народ требует теста и более подробной информации.

И вот тоже вопрос — у меня swap + ram = 12GB, а мне нужно хранить 40GB. получается с Redis этого не сделать и нужно использовать memcachedb, т.к. там в памяти сидят только те данные, которые наиболее активно используются. В данном случае алгоритм работы memcached весьма подходящий и авторам Redis стоило бы его добавить, как опцию. Иначе для серьёзных вещей использовать не получится.
просто он не предназначен для дискового хранения. и все. Это не значит, что серьезно/не серьезно. Просто другое. И не надо добавлять — он покрывает свою нишу, где надо от диска отвязаться.
Суть вопроса была в другом, что от диска я и так отвяжусь, но хранить огромную базу в памяти мне не надо — только ту часть, которая используется. Иначе получается, что для больших баз он экономически просто не выгоден.

memcachedb какраз предназначен именно для дискового хранения — он использует berkleydb как backend со всеми вытекающими возможностями — размазывание ключей по пачке серваков + berkleydb репликация., т.е. можно держать бекапы и распределять данные между несколькими кластерами.
Согласен, направление интересное.
Вот только упокоившееся :-(
Да, ставить 48GB RAM в сервак не вариант, когда активно используется порция в 2-3GB новых актуальных данных.
Достаточно будет поставить 8 гиг и 40 гиг свопа.
И 48GB ещё на саму базу — т.е. всего это сожрёт 48 + 40 = 88GB места на диске, вместо 48.
Плохо.
Ну дык это же база данных в памяти а не диске.
В памяти 8 Гб, а 40 в swap, тоесть на диске.
я про то что вообще она должна быть в памяти целиком, а не диске. Если часть памяти на диске это не ее проблемы. К тому же если данных порядка 2-3 гиг в зависимости от алгоритма 40 гиг могут из свапа не доставаться вообще.
Вы забываете про 48 гигов, которые нужно хранить в базе на диске. Потому что RAM и swap файл это временное хранилище. К тому же холодный старт требует загрузить 48GB в RAM, что с учётом записи в swap 100% уполовинит максимальные скорости чтения и записи на диск до района 30-40MB/sec, т.е. надо ставить 2 диска минимум. Возмём ситуацию с 2-мя скоростными SAS дисками на 15к rmp для примера — 49 152 MB / 90 MB/sec (средняя скорость записи на диск) = 546 секунд, т.е. 9.12 минуты для того, что бы стартануть Radis. А если диск будет только один — время возрастёт в двоё в лучшем случае, а то и больше. С memcachedb такого нету, потому что сам memcache работает как кеширующая прослойка и вбирает данные в кеш при их запросе, а berkleydb позволяет обрабатывать зверское кол-во запросов в секунду.
Так же есть патчи для memcache, которые позволяют выжать из memcache все соки, а патчи к ядру от Facebook вообще дают запредельные цифры — по 600-700к в многопоточном режиме.

Так что, ИМХО, авторам Redis надо работать в этом направлении, иначе апгрейд версии Redis с базой на 5-6 гигов выльется в простой в 3-4 минуты в лучшем случае, а содержание базы больше 10-15 гигов не имеет смысла — в таком случае просто ставим InnoDB огромный буфер и вся база легко сидит в памяти, а добавление MySQL NDB Cluster делает всё ещё круче, и не надо уходить от базы данных вообще, да ещё и отказоустойчивость из разряда 99.999%.
собтвенно а почему бы не использовать их в связке?
говоря о тестах вот инфо с нашего текущего:
array(13) {
  ["redis_version"]=>
  float(0.9)
  ["uptime_in_seconds"]=>
  int(605114)
  ["uptime_in_days"]=>
  int(7)
  ["used_memory"]=>
  int(315368975)
  ["changes_since_last_save"]=>
  int(7598)
  ["bgsave_in_progress"]=>
  int(0)
  ["total_connections_received"]=>
  int(5483580)
  ["total_commands_processed"]=>
  int(43263255)
  ["role"]=>
  string(6) "master"
  ["db0"]=>
  string(21) " keys=54464,expires=0"
}
Из замеченных проблем:
Однопоточный, использует только одно ядро на машине.
При достижении процессом сервера нагрузки одного ядра в 100% начинает активно протекать память.

С другой стороны, в Редисе отлично сделана репликация. Чего не сказать о memcachedb. У меня она так и не завелась — через минуту работы все сервера начинали писать о поврежденной БД.
UFO just landed and posted this here
так что же ты хотел, размеры указателей увеличились вдвое :)
и не только Редис разбухает на 64 бит ось. Почитай топики — и апач пухнет и др процессы почти в два раза.

ну а что касается — кушает много памяти при небольшом объеме данных — то за скорость надо платить!
Не нужен, а то напишут криво, как libmemcached, а потом в блогах будут заметки «Как я героически искал сигфолт» или форумы завалят вопросами «Почему падает РНР, вроде из модулей ничего такого нет, мускуль, имиджмагик, да мемкеш»
Обновил пост, поставил ссылку.
хочу заметить что Си экстеншен писали идиоты и его нельзя использовать на продакшене. (сплошные утечки памяти). fixxxer (ник от fix — все фиксить) его пофиксил и выслал патч автору, но воз и ныне там.
жаль на некоторых хостингах все еще стоит PHP >= 4.2, и Redis не используешь
Sign up to leave a comment.

Articles