Читаю внимательно про redis, и нахожусь в смятении.
Похоже я чего-то не понимаю, или redis реально стоит использовать только в качестве кэша, всяких autocomplete и прочего подобного.
Итак, читаем в документации: «Snapshotting is not very durable. „ IS NOT VERY!
Такими словами они приоритетными помечают те проекты, где сохранность данных не важна.
Как такое может быть? Сохранность не важна или не критична только в случае кэширования или логирования чего-нибудь, но ведь они себя не позиционируют именно для таких проектов…
Да и как вообще можно допускать потерю даже одного ключа в иных случаях? Допустим, snapshotting выполняется каждую минуту. Между действием регистрируется пользователь на сайте, затем сервер крашится, пользователь удаляется, нормально, да?:)
Дальше смотрим решение AOF… Вроде бы учли проблему, но…
В документации описано три типа сохранения данных в aof-файл: при каждом запросе (что единственный способ гарантировать сохранность более менее), каждую секунду, никогда.
И меня убило тут то, что они рекоммендуют второй способ — каждую секунду. Very fast and PRETTY SAFE!
При этом они отмечают, что можно потерять данные, которые были добавлены за секунду. И относятся к этому так же спокойно.
Я не понимаю.
Прошу помощи у знающих, чтобы они смогли мне показать то, чего я не понимаю здесь, и объяснить мне стоит ли при таком раскладе полностью переходить на NoSQL? Уж очень меня заинтересовала эта штука, сижу и радуюсь, как в первый раз в жизни открыл для себя mysql после работы с файлами :))
Как говорится: «любишь кататься, люби и саночки возиться».
Если вам нужна производительность в любом случае вы будете жертвовать надежностью.
Если по теме — используйте репликацию. Использовать fsunc при каждой записи как то глупо.
Ну и не по теме — если сервер ляжет в процессе записи данных в mysql с ними случится ровно тоже, что и при записи в Redis, MongoDB или любую другую noSql базу
Да, редис привлекателен в первую очередь из-за скорости. Это скорее альтернатива memcached чем БД, на которой можно полностью строить приложение. При проектировании одной игры мы делали следующее: перед боем данные из бд подгружались в редис, во время боя использовался только редис, после боя записывали результаты назад в MySQL.
Редис ведь база ключ-значение, на ней сложно построить сложную архитектуру? А вот для вещей которые вы сказали очень хороши для редиса. Общался с одним из разработчиков редиски (надстройка над редисом) и он не раз говорил что редис как средство для кеширования хорош, но вот как первичное хранилище не советовал.
Переходить на nosql полностью не советую сразу. Выделите для nosql некий набор данных (например сообщения, или инфо) и работайте лишь с этим кусочком, тогда сами поймете что он может а что нет, стоит он того или нет. А вообще nosql хорошая штука.
В какой-то степени это так. Но я прочитал пример создания клона твиттера на nosql и впечатлился. Конечно, сложную архитектуру создать почти нереально, нет нужного функционала как в SQL, однако зачем нужна эта сложная архитектура? Помнится я был новичком в mysql и даже не знал, как использовать join-ы, и это никак не мешало мне писать приложения. Да, было менее удобно и много лишних запросов, но это ведь не играет большой роли в случае nosql.
Не, «клон твиттера» или блог хороши для nosql, но если пойдете выше, mongodb и аналоги, более «гибкие» чем редис вам помогут по началу. Проблема nosql (я перейду на монго, не знаю как редис) и одно временно преимущество, в том что он хранит ключи в памяти, это представляет очень быстрый доступ к данным. Но памяти обычно меньше чем винта, поэтому следить надо очень сильно за ним. С другой стороны, если вы хотите использовать nosql как обычную реляционную структуру, то в этом нет смысла, есть хорошие реляционные бд (mysql, posgree итд). Тут важен сам принцип, и его нужно использовать только если Вы понимаете _зачем_ оно Вам надо. если просто радис корости, то не стоит заморачиваться. Там другой подход совершенно, и в этом вся прелесть.
Мне просто нравится сам подход, он прост. А скорость это уже следствие простоты :)
Проблема с нехваткой памяти решается шардингом редкоиспользуемых ключей на диск (умеет redis), либо можно на стороне клиента раскидывать разные «группы» данных по разным серверам. А на подходе redis-cluster, там еще круче всё будет :)
Ну, раз Вы уже все вычитали, то я б занялся этим, я собирался в свое время, но мне сказали "..." на работе, мол сиди со своим мускулом, нас и с ним неплохо кормят. Поэтому мои знания чисто теоретические. А насчет того что данные «вполне» надежно хранятся это да, это больше стоит смотреть типа «Если че, мы вас предупреждали», чем на то что она падает регулярно =) Не так страшен черт как его рисуют. Бэкапы спасут мир =)
Ага, простейшее решение проблемы — репликация. По началу можно просто на дешевый бэкап-сервер, где данные будут в свопе и пофиг :) Запросы всё равно обслуживать не будет.
Хотел тоже вопросик задать. А что если в редиске хранятся локали (ключ — ru.hello_world, значение — 'Привет, мир!'). Данные меняются максимум раз в год. Как тут с сохранностью? Есть ли шанс потерять все (или часть)?
В зависимости от настроек, изменения раз в # секунд скидываются на диск. Если изменений нет — на диске просто лежит копия данных, которая поднимается при рестарте. Если сервер умрет в процессе записи новых ключей — у вас потеряются только изменения (старый файл с дампом никуда не денется, пока нет уверенности, что уже есть новый). Соответственно, шанс потерять все данные == шансу смерти вашей системы хранения данных.
Простой
Простой
Сложный
Средний
Простой
