Comments 126
Заманчиво. Современным веб разработчикам думаю не хватает такой легковесненькой очень быстрой нереляционной БД. А может просто мозгов не хватает и все по старинке юзают MySQL.
Большинство начинающих веб-разработчиков, по моему наблюдению, не думают о производительности своего приложения. Вон сколько книг «PHP5+MySQL» продаётся. Таким образом начинающего программиста сразу приучают хранить все данные в MySQL.
В то же время, Redis достаточно, по крайней мере для 80% всех проектов.
В то же время, Redis достаточно, по крайней мере для 80% всех проектов.
Как ни крути, а большинство все таки пишет для площадок которые дают хостеры, либо необходимы унифицированные решения, что б опять же клиент мог повесить на каком почти бесплатном хосте, для людей которым производильность пофигу(как в прочем и сам сайт).
Как часто на хостах есть, что то кроме мускула(ну пусть постгре еще), в большинстве случаев стоит говорить спасибо уже за то чтоб сесию не в общий темп сваливали.
Это не книжки приучают, это рынок проводит селекцию.
ЗЫ: сейчас опять приходится писать унифицированную систему, с расчетом на такие древности которые лучше не поминать в суе:-(… И скучаю, по возможности попрерикаться с одмином, о том как сделать что б это все «летало»
ЗЫ2: жарко кондей не справляется, оптимизму чет совсем мало.
Как часто на хостах есть, что то кроме мускула(ну пусть постгре еще), в большинстве случаев стоит говорить спасибо уже за то чтоб сесию не в общий темп сваливали.
Это не книжки приучают, это рынок проводит селекцию.
ЗЫ: сейчас опять приходится писать унифицированную систему, с расчетом на такие древности которые лучше не поминать в суе:-(… И скучаю, по возможности попрерикаться с одмином, о том как сделать что б это все «летало»
ЗЫ2: жарко кондей не справляется, оптимизму чет совсем мало.
Хостеры могут сэкономить себе много сил, нервов и финансов, установив такую штуку как Reds и приучив к нему программистов.
Сейчас ресурсы хостингов расходуются пользователями уж очень не оптимально, но виноваты в этом скорее разработчики скриптов.
Если бы тот же (прости госпади) 1С Битрикс работал на Redis, то уверен, все хостинги мигом бы организовали бы у себя Redis-сервера.
И главное, что все бы выиграли: заказчики и конечные пользователи получили бы большую скорость работы сайта, хостинги получили бы снижение нагрузки на своё железо, а следовательно финансовую экономию.
Сейчас ресурсы хостингов расходуются пользователями уж очень не оптимально, но виноваты в этом скорее разработчики скриптов.
Если бы тот же (прости госпади) 1С Битрикс работал на Redis, то уверен, все хостинги мигом бы организовали бы у себя Redis-сервера.
И главное, что все бы выиграли: заказчики и конечные пользователи получили бы большую скорость работы сайта, хостинги получили бы снижение нагрузки на своё железо, а следовательно финансовую экономию.
Вопрос, а зачем? если и так все довольны.
Не устраивает, что стоит на сервере покупай вдс или дедик… вперед. И будет тебе и редиска и сосиска и что душе угодно.
Оно ни кому не надо(вру, есть те кому надо и это вселяет надежду), именно потому слишком часто приходится слышать пхп=говно. ИМХО пхп != говно, но нормально им пользуется не так много человек. Большинство для того что б написать говно-код, потому как сайт надо сдать вчера, а книжку по пыху купил только сегодня.
Отсутсвие зрелых инструментов и постоянная необходимость поддердивать подобные чудо-творения, наводят все большее желание перейти куда нить на яву или питон:-(… хотя хорошо, там где нас нет
Не устраивает, что стоит на сервере покупай вдс или дедик… вперед. И будет тебе и редиска и сосиска и что душе угодно.
Оно ни кому не надо(вру, есть те кому надо и это вселяет надежду), именно потому слишком часто приходится слышать пхп=говно. ИМХО пхп != говно, но нормально им пользуется не так много человек. Большинство для того что б написать говно-код, потому как сайт надо сдать вчера, а книжку по пыху купил только сегодня.
Отсутсвие зрелых инструментов и постоянная необходимость поддердивать подобные чудо-творения, наводят все большее желание перейти куда нить на яву или питон:-(… хотя хорошо, там где нас нет
Есть Google App Engine :) с их БД. Если бы у меня не было своего дедика, то я бы писал проекты под него)
80% проектов не требуется реляционная модель данных?
мне кажется, Вы преувеличиваете.
мне кажется, Вы преувеличиваете.
Возможно вы правы, но по моему скромному мнению, доля таких проектов существенна.
сама структура сайта подразумавает реляционность. чтобы ее реализовать, придется либо велосипедить в коде программы, либо выносить взаимоотношения данных в отдельное хранилище (xml, например), что не есть правильный путь, по-моему.
вообще, я согласен с этим комментарием. сравнение redis с БД не совсем уместное, по-моему.
даже если в данный конкретный момент можно ограничиться redis-ом, при развитии проекта начнутся сложности, которые рано или поздно приведут к реляционной модели данных.
вообще, я согласен с этим комментарием. сравнение redis с БД не совсем уместное, по-моему.
даже если в данный конкретный момент можно ограничиться redis-ом, при развитии проекта начнутся сложности, которые рано или поздно приведут к реляционной модели данных.
Согласен, велосипеды — плохо. Можно связи и информацию для сложных выборок хранить в MySQL, а простые данные — в Redis.
Я не столько призываю заменить MySQL Redis'ом, сколько хочу обратить внимание на быстрые и простые хранилища для тех данных, которым не требуется реляционность.
Я не столько призываю заменить MySQL Redis'ом, сколько хочу обратить внимание на быстрые и простые хранилища для тех данных, которым не требуется реляционность.
структура сайта подразумевает реляционность? Окститесь. Чего-чего, а реляционности там кот наплакал.
начинающие веб-разработчики по природе своей не должны задумываться о производительности — у них и других проблем хватает. Например: изучение собственно предметной области. А вот оптимизация и прочие хайлоады — это уже удел совсем не начинающих.
т.е. кто-то не согласен, что сначала веб-разработчик должен научиться программировать, а потом уже заниматься performance optimization? ;-) хехе…
performance optimization должна быть по ходу написания и проектирования проекта, а не тогда когда уже «совсем туго стало»
или я неверно выразился, или вы меня неправильно поняли. попробую расшифровать свой коммент:
ну так вот, повторюсь: начинающим разработчикам следует сосредоточиться на умении писать гибкий и поддерживаемый код. А умение оптимизировать и писать код под нагрузки — это задача для более опытных коллег. Согласны? :-)
coolspot:
Большинство начинающих веб-разработчиков, по моему наблюдению, не думают о производительности своего приложения.
ну так вот, повторюсь: начинающим разработчикам следует сосредоточиться на умении писать гибкий и поддерживаемый код. А умение оптимизировать и писать код под нагрузки — это задача для более опытных коллег. Согласны? :-)
нет конечно :)
Оптимизация это же не какая то страшная тайна в которою просвещают только избранных, конечно же, согласен, что эти знания приходят в основном с опытом. Но если человек учится писать гибкий и красивый код, так почему он должен опускать оптимизационные моменты, зачем ?, чтобы потом переделывать «правильно»?
например взять mySQL ?, некоторые люди умудряются завалит весь сайт одним запросом, а все из за того что он пропустил раздел где рассказывали например о индексах, или сортировке данных, зачем он их пропустил? да потому что ему сказали что он начинающий программист, и ему ненужно читать об оптимизации :)
Оптимизация это же не какая то страшная тайна в которою просвещают только избранных, конечно же, согласен, что эти знания приходят в основном с опытом. Но если человек учится писать гибкий и красивый код, так почему он должен опускать оптимизационные моменты, зачем ?, чтобы потом переделывать «правильно»?
например взять mySQL ?, некоторые люди умудряются завалит весь сайт одним запросом, а все из за того что он пропустил раздел где рассказывали например о индексах, или сортировке данных, зачем он их пропустил? да потому что ему сказали что он начинающий программист, и ему ненужно читать об оптимизации :)
нет конечно :)
Но если человек учится писать гибкий и красивый код, так почему он должен опускать оптимизационные моменты, зачем ?
не хотелось бы разводить холивары, но не ответить не могу: гибкий, качественно написанный код оптимизировать проще. т.е. сначала пишем хорошо, потом смотрим, что тормозит, потом оптимизируем то, что тормозит. как-то так.
например взять mySQL ?, некоторые люди умудряются завалит весь сайт одним запросом, а все из за того что он пропустил раздел где рассказывали например о индексах, или сортировке данных, зачем он их пропустил? да потому что ему сказали что он начинающий программист, и ему ненужно читать об оптимизации :)
а это и есть опыт :-)))
Да, но всё же многим начинающим разработчикам большие реляционные возможности MySQL совсем не нужны. Они очень часто используют реляционную БД для хранения плоских данных ключ-значение.
Возможно по поводу 80% я преувеличил, но согласитесь, большое количество задач не требует реляционной модели данных.
Возможно по поводу 80% я преувеличил, но согласитесь, большое количество задач не требует реляционной модели данных.
Интересно что же подразумевается вами под «80% всех проектов» в интернете. В эти 80% «интернет магазин» попадает по-вашему?
По моему нереляционная модель БД может использоваться только для кеширования.
Ну и конечно же можно использовать на сайта-штамповках, все данные для которых можно сохранить даже под одним ключом в нереляциоонной БД. я надеюсь вы не относите сайты-штамповки к определению «проект»
По моему нереляционная модель БД может использоваться только для кеширования.
Ну и конечно же можно использовать на сайта-штамповках, все данные для которых можно сохранить даже под одним ключом в нереляциоонной БД. я надеюсь вы не относите сайты-штамповки к определению «проект»
почему тогда всем монстры используют их «не только для кеширования»? Гугл, линкедин, фейсбук, амазон и другие…
хм. ну да, конечно же нереляционная модель удобна там где намного удобнее лишь хранить данные как ключ-значение.
но, мы же не забываем что «Гугл, линкедин, фейсбук, амазон и другие… » используют нереляционную БД как дополнительную к реляционной-основной? Ими нереляционная модель БД в основном используется для кеширования
но, мы же не забываем что «Гугл, линкедин, фейсбук, амазон и другие… » используют нереляционную БД как дополнительную к реляционной-основной? Ими нереляционная модель БД в основном используется для кеширования
а кто вам мешает эти связи реализовать в key/value стораджах?
comments:$user_id
comment:id
comment:id
comment:id
и
comment:$id
comment:date
comment:body
?
и на выходе 2 быстрых запроса к стораджу, а не сиквельный join.
comments:$user_id
comment:id
comment:id
comment:id
и
comment:$id
comment:date
comment:body
?
и на выходе 2 быстрых запроса к стораджу, а не сиквельный join.
ну допустим нужно получить список последний 10 продуктов. тогда мне нужно использовать дату как ключ иначе мне придется выдернуть все продукты и проверить дату.
а хранение товаров тоже проблематичным становится?
1. допустим храним все товары в одном масиве под одним ключем, тогда чтобы показать один единственный товар — в память загрузится весь список продуктов а потом уже из этого списка и возьмем нужный нам товар. — это плохо неоптимальное использование памяти
2. допустим наоборот, мы храним все товары под своими ключами — тогда чтобы показать список товаров на придется пробежаться по всей бд и выдернуть все ключи с префиксом product:
а хранение товаров тоже проблематичным становится?
1. допустим храним все товары в одном масиве под одним ключем, тогда чтобы показать один единственный товар — в память загрузится весь список продуктов а потом уже из этого списка и возьмем нужный нам товар. — это плохо неоптимальное использование памяти
2. допустим наоборот, мы храним все товары под своими ключами — тогда чтобы показать список товаров на придется пробежаться по всей бд и выдернуть все ключи с префиксом product:
Не путайте теплое с мягким. У БД и кеширующего хранилища достаточно разные задачи и области применимости. Если не требовать от БД Atomicy, Consistency, Integrity, Durability, реляционности и поддержки SQL (читай, концепции связанных таблиц и инструмента для оперирования данными), то она будет летать.
Я особо и не путаю. Просто большинству сайтов не нужны эти фишки, вплодь до того что реляционность даже не нужна многим. Контент обычно слабосвязан.
Контент обычно слабосвязан.
Да бросьте Вы. Приведите пример сайта, где контент слабо связан.
Любой бложек. А облако тегов можно реализовать за счет таблиц ссылкок.
БОльшая часть контента сайтов и порталов это кешированный контент, для хранения которого используется или следует использовать key/value, это во-первых.
И даже сам URL этой страницы — является по сути своей ключом.
В случае с реляционной моделью, запрос включал бы выборку страницы по id и выборку комментариев, parent_id у которых был бы равен этому id.
В нереляционной модели, эта страница хранится, как единственный объект (документ) в хранилище и при добавлении комментария обновляется.
Вместо такой лаконичности, мы должны иметь 2-3 таблицы, которые связаны через некоторое поле.
Не кажется хаком? Особенно при условии, что иерархия комментариев всё равно существует лишь на программном слое, потому что хранить ветки комментариев в виде некой структурой с реляциями это безумие.
В любом случае в key/value можно эмулировать связи там, где они нужны.
И даже сам URL этой страницы — является по сути своей ключом.
В случае с реляционной моделью, запрос включал бы выборку страницы по id и выборку комментариев, parent_id у которых был бы равен этому id.
В нереляционной модели, эта страница хранится, как единственный объект (документ) в хранилище и при добавлении комментария обновляется.
Вместо такой лаконичности, мы должны иметь 2-3 таблицы, которые связаны через некоторое поле.
Не кажется хаком? Особенно при условии, что иерархия комментариев всё равно существует лишь на программном слое, потому что хранить ветки комментариев в виде некой структурой с реляциями это безумие.
В любом случае в key/value можно эмулировать связи там, где они нужны.
для рhp есть еще одна реализация code.google.com/p/imemcacheclient-php/source/browse/trunk/Redis.class.php которая работает с несколькими серверами одновременно и код написан для php5
у меня есть также класс, работающий с несколькими серверами, и другие плюшки вроде сериализации. code.google.com/p/redis-ajax-chat/source/browse/trunk/lib/Redis_Server.php однако это устаревшая уже версия, новую на днях выложу и буду работать над полной поддержкой 1.0 версии.
эх, опередили меня с статьей о редисе, но ничего :)
эх, опередили меня с статьей о редисе, но ничего :)
Обновил топик — упомянул IMemcacheClient
скорее уже с проектами заслуживающими доверие code.google.com/u/kak.serpom.po.yaitsam/
Отлично, push/pop это как раз то, чего не хватает в memcached! Присмотрюсь, т.к. memcached использую в полную катушку.
Вопрос только, что за backend хранит данные на диске? Или у вас свой собственный формат хранения данных?
Вопрос только, что за backend хранит данные на диске? Или у вас свой собственный формат хранения данных?
А вообще есть опыт использования этой штуки в действительно большой проекте? Я работаю над социальной сеткой с весьма богатым функционалом, там хранится не только данные будут, но и очень много всяких флагов на сессию, т.е. должен быть так же expire time. А использовать сразу два хранилища весьма накладно по железкам будет.
требует много памяти. однако работает шустро, а специальные типы данных очень упрощают жизнь и архитектуру. Используем в крупном проекте приближенном к реалтайму.
а вы посмотрите в примерах — там упрощённый твиттер-клон на пхп под редис.
недавно для в одном проекте попробовали в качестве хранилища для юзер ивент лога, пока очень довольны.
кстати redis manager никто не запускал? а то что то не получается пока что.
кстати redis manager никто не запускал? а то что то не получается пока что.
Есть ещё вот такая штука couchdb.apache.org
Какого размера может быть база? Возможно ли динамическое создание баз и их одновременное использование? Как сказывается размер базы на быстродействии?
какого нужно. да возможно, практически не сказывается, потому как постоянно данные в оперативке, и в зависимости от ваших настроек время от времени сохраняется на жёсткий диск.
Но ведь оперативки гораздо меньше, чем диска. Наверное все же хранится лишь актуальная часть данных там?
Хранятся все данные. Если во время работы данных становится больше, чем оперативной памяти, то используются возможности ОС — swap.
Таким образом, после перезагрузки и очистки swap, данные не уместившиеся в RAM будут утеряны.
Ответы об этом в FAQ проекта.
Таким образом, после перезагрузки и очистки swap, данные не уместившиеся в RAM будут утеряны.
Ответы об этом в FAQ проекта.
Хорошо подругому задам вопрос. Вот у меня есть машина с 2 гигабайтами памяти, что будет если база 6 гиг?
это же серверное решение, к тому же распределенное. сервера бывают и с 32 Гб памяти и больше…
это же серверное решение, к тому же распределенное. сервера бывают и с 32 Гб памяти и больше…
Типа дабавляйте память до упора? Оно как-то вообще уведомляет что у нас скоро кончится память и надо что-то делать или как? Просто мне не шибко нравится ситуация когда я добавляю в базу данные, а она внезапно падает.
2 Гига будет в RAM, 4 Гига в swap.
Работать Redis будет непредсказуемо то быстро, то медленно, в зависимости от того, где находятся запрашиваемые данные, в swap или в RAM.
Во время работы Redis, согласно своей архитектуре, будет скидывать данные из RAM (swap) на жёсткий диск, что иногда будет приводить к абсурдному копированию с диска на диск (из swap в файл-хранилище).
Освещение этого вопроса в FAQ проекта.
Работать Redis будет непредсказуемо то быстро, то медленно, в зависимости от того, где находятся запрашиваемые данные, в swap или в RAM.
Во время работы Redis, согласно своей архитектуре, будет скидывать данные из RAM (swap) на жёсткий диск, что иногда будет приводить к абсурдному копированию с диска на диск (из swap в файл-хранилище).
Освещение этого вопроса в FAQ проекта.
А размер базы задать жестко можно? Чтоб оно ругалось что мем закончился сделайте ченить.
Пока такая штука только в планах разработчиков. Сейчас узнать, что память кончилась и в ход пошёл swap можно только по начавшимся тормозам.
Авторы рекомендуют использовать уже существующую команду INFO для получения количества израсходованной памяти, для своевременного увеличения её объёма. =)
Авторы рекомендуют использовать уже существующую команду INFO для получения количества израсходованной памяти, для своевременного увеличения её объёма. =)
ну в принципе, это можно закодировать в клиент. Если есть запрос со стороны сообщества, в своем классе на РНР я бы мог такое сделать (правда, некоторой ценой потери скорости работы, но увы).
сейчас поддерживается до 16 баз, да, можно параллельно хоть все использовать (удобнее, если клиент поддерживает это, иначе вручную переключаться надо будет в запросах). Размер, в принципе, влияет на скорость сохранения, однако, это сложный вопрос (запись асинхронная, и если за промежуток от первого сохранения не добавлено пару гиг, то не сказывается, однако это настраиваемо вполне). Влиять будет подьем базы с дисковой копии при рестарте сервера.
У меня просто есть мысль использовать такого рода базу для хранения ключ-данные, где ключ это id + timestamp. Ну и что не мало важно данные могут требоваться переодически. Есть небольшой набор оперативных данных и большой набор не оперативных данных (к примеру по дням). До Redis я хотел посмотреть berkley db 4.
да, вполне, я так делал для чата. можно еще организовать в списки или скомбинировать. вполне рабочий вариант.
У меня не чат, у меня сервер мониторинга. Просто есть мысль брать оперативные данные и более старые данные из сегментов. Я вот начинаю подозревать, что если для оперативных данных redis подойдет, то вот для не оперативных как-то будет не очень.
важно, что принцип ключей по таймстампу работает, можно еще группировать по временным отрезкам и хранить списки (например, список на каждый отрезок времени минутный).
Да, как прокси-кеш он отлично работает. В аналогичном сервере мониторинга логов работает (на сайте есть новость про использование в каком-то сервисе, мы также думаем вот сделать адаптер для Zend_Log чтобы туба писать логи, а сервер статистики будет забирать периодически данные и записывать уже для долгосрочного анализа.
Да, как прокси-кеш он отлично работает. В аналогичном сервере мониторинга логов работает (на сайте есть новость про использование в каком-то сервисе, мы также думаем вот сделать адаптер для Zend_Log чтобы туба писать логи, а сервер статистики будет забирать периодически данные и записывать уже для долгосрочного анализа.
Для не оперативных лучше MemcacheDB.
А он поддерживает конкурентный доступ?
Я имел ввиду, что если суммарный размер данных превышает размер оперативной памяти, то Redis будет фигово работать: во время запуска он будет загружать данные из файла-хранилища в оперативку, если в RAM не влезет — он пойдёт во все тяжкие в swap и так пока все данные не окажутся в виртуальной памяти.
MemcacheDB же загрузит в оперативную память столько, сколько указано в конфиге, а остальное оставит лежать на диске. Если к каким-то данным будут обращаться чаще других — он их положит в RAM надолго.
MemcacheDB же загрузит в оперативную память столько, сколько указано в конфиге, а остальное оставит лежать на диске. Если к каким-то данным будут обращаться чаще других — он их положит в RAM надолго.
Классная штука. Memcache проигрывает.
этим мартом сравнивал Redis с другими cache системами (на обывательском уровне), возможно, кому-то это будет интересно:
результаты: www.sicoro.com/.pub/cache-diagrams.ods
код (symfony front controller): www.pastie.org/551993
мой доп. плагин sfRedisCache: www.pastie.org/414802
результаты: www.sicoro.com/.pub/cache-diagrams.ods
код (symfony front controller): www.pastie.org/551993
мой доп. плагин sfRedisCache: www.pastie.org/414802
а что насчет php/apache под windows?
PHP, установленный на Windows, может обращаться к Redis-серверу установленному на *nix пр помощи TCP/IP =)
Redis — сервера для Windows, пока, нет.
Redis — сервера для Windows, пока, нет.
есть :) code.google.com/p/redisdb-win32/
Круто, дома сравню memcache, mysql и tokyo
З.Ы. Извините, а что за тег «плохой человек»? :)
З.Ы. Извините, а что за тег «плохой человек»? :)
Интересно, как с производительностью относительно MangoDB? Пользуюсь ей, очень рад пока.
может вы имели ввиду MongoDB, от Стартапа 10gen, которые делали интересную платформу для клоуда, а потом переключились на ее основной компонент — базу
Да, заработался видимо :) Конечно Mongo :)
Кстати, интересная штука. Тем, кому интересно — www.mongodb.org/display/DOCS/Home
А вы могли бы написать пост о ней? как практик, а то я собираюсь также, но больше в теории. И скажите еще, плиз, с ней можно работать с РНР без расширения, через сокеты например? Иначе это существенное ограничение (для меня, как минимум).
А вы могли бы написать пост о ней? как практик, а то я собираюсь также, но больше в теории. И скажите еще, плиз, с ней можно работать с РНР без расширения, через сокеты например? Иначе это существенное ограничение (для меня, как минимум).
IMemcacheClient поддерживает Redis — habrahabr.ru/blogs/php/57984/
Сайт — code.google.com/p/imemcacheclient-php/
Сам коннектор — code.google.com/p/imemcacheclient-php/source/browse/trunk/Redis.class.php
Сайт — code.google.com/p/imemcacheclient-php/
Сам коннектор — code.google.com/p/imemcacheclient-php/source/browse/trunk/Redis.class.php
Вобщем народ требует теста и более подробной информации.
И вот тоже вопрос — у меня swap + ram = 12GB, а мне нужно хранить 40GB. получается с Redis этого не сделать и нужно использовать memcachedb, т.к. там в памяти сидят только те данные, которые наиболее активно используются. В данном случае алгоритм работы memcached весьма подходящий и авторам Redis стоило бы его добавить, как опцию. Иначе для серьёзных вещей использовать не получится.
И вот тоже вопрос — у меня swap + ram = 12GB, а мне нужно хранить 40GB. получается с Redis этого не сделать и нужно использовать memcachedb, т.к. там в памяти сидят только те данные, которые наиболее активно используются. В данном случае алгоритм работы memcached весьма подходящий и авторам Redis стоило бы его добавить, как опцию. Иначе для серьёзных вещей использовать не получится.
просто он не предназначен для дискового хранения. и все. Это не значит, что серьезно/не серьезно. Просто другое. И не надо добавлять — он покрывает свою нишу, где надо от диска отвязаться.
Суть вопроса была в другом, что от диска я и так отвяжусь, но хранить огромную базу в памяти мне не надо — только ту часть, которая используется. Иначе получается, что для больших баз он экономически просто не выгоден.
memcachedb какраз предназначен именно для дискового хранения — он использует berkleydb как backend со всеми вытекающими возможностями — размазывание ключей по пачке серваков + berkleydb репликация., т.е. можно держать бекапы и распределять данные между несколькими кластерами.
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%.
Так же есть патчи для 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. У меня она так и не завелась — через минуту работы все сервера начинали писать о поврежденной БД.
Однопоточный, использует только одно ядро на машине.
При достижении процессом сервера нагрузки одного ядра в 100% начинает активно протекать память.
С другой стороны, в Редисе отлично сделана репликация. Чего не сказать о memcachedb. У меня она так и не завелась — через минуту работы все сервера начинали писать о поврежденной БД.
UFO just landed and posted this here
Неужели нет API для Си?
Официального API на C нет, но все команды для сервера документированы, так что общаться с сервером по сокетам — не проблема.
Не нужен, а то напишут криво, как libmemcached, а потом в блогах будут заметки «Как я героически искал сигфолт» или форумы завалят вопросами «Почему падает РНР, вроде из модулей ничего такого нет, мускуль, имиджмагик, да мемкеш»
Rediska — PHP клиент: habrahabr.ru/blogs/webdev/76388/
хочу заметить что Си экстеншен писали идиоты и его нельзя использовать на продакшене. (сплошные утечки памяти). fixxxer (ник от fix — все фиксить) его пофиксил и выслал патч автору, но воз и ныне там.
жаль на некоторых хостингах все еще стоит PHP >= 4.2, и Redis не используешь
Only those users with full accounts are able to leave comments. Log in, please.
Redis — высокопроизводительное хранилище данных