тарантул 1.6 будет использовать вид хранения msgpack, а с внедрением этой фичи можно уже говорить о документно-ориентированности. По функциональности тарантул во многом превосходит редис.
не плохой обзор, полезно начинающим… но хотелось добавить следующее:
1) практика показывает, что на сайтах производителей тесты не всегда объективны и их лучше делать самому.
порой у меня тесты отличались на 50-250% процентов от заявленного,
все ИМХО зависит от методике тестирования и железа. По этому тесты делаем сами, а не ведемся на марткетинговые ходы.
2) что касается тарантула, то последние новости: в tarantool 1.6 в связи с переходом на FFI Lua производительность поднялась в от 20% до 800% и можно говорить о производительности от 1.2М до 5М (на разные виды операций)
3) Neo4j не единственная графовая БД :
как выше сказал Stdit, применение ORM специфично и покрывает большинство простых бизнес задач. Однако, когда ты начинаешь использовать специфичные запросы или сталкиваешься с нагрузкой — то эта лишняя абстракция, лишний код который тратит ресурсы.
Лично я за правильное ООП, где должен быть DataObject. И пусть в нем маппинг не автоматизированный, но он прозрачен для программиста и при необходимости данный маппинг можно правильно с оптимизировать, а не гадать на кофейной гущи ORM. И пусть такие товарищи, как Fesor сколь угодно кричат, что зло, а что добро, но я последние пять-семь лет больше занимаюсь переделыванием и оптимизацией чужого говнокода, про архитектуру которого и не задумывались, где можно было написать по уму, используя всего лишь треть нормальных запросов…
Бл. наболело. ;(
Серия Эльбрус» советских многопроцессорных суперкомпьютеров, разработанных в ЛИТМО (ныне ИТМиВТ) в 1970—1980-х годах, кластер на базе БЭСМ-6 (Большая Советская вычислительная машина).
Мой отец имел опыт разработок на этих компьютерах, были расчеты связанные с космическими технологиями. На сколько мне известно, но история замалчивает, что ЦРУ запустило дезинформацию о выгодности технологии IBM 360/370 и нашим правительством была закуплена через посредничество Франции технология производства IBM 360, Однако документации по математическому обеспечению не передали, на верху порешили, что не дураки и сами разберемся. В результате мы с десятилетнем опозданием запустили ЕС-совскую серию: ЕС 1022, ЕС 1033., тем самым закрыв инвестиции в технологию БЭСМ и Эльбрус. Этим политическим решением мы закрыли свои наработки и принялись осваивать уже на этом момент устаревшию ЕС-совскую серию в чем опоздали скорее всего уже навсегда.
Более менее нормальная литература по этой тематике появилась с десятилетним опозданием. Это были мои студенческие годы. Хитовой книгой моей юности была: Джермейн. «Программирование на IBM 360»…
Вся вышеизложенная информация — это лишь мнение моего отца, который был тесно связан с разными IT технологиями в космической индустрии.
В ходе моей студенческой жизни пришлось работать и в упомянутом в статье альфа-транслятором… Да, были интересные и увлекательные времена… К сожалению, со звездами IT индустрии мне не удалось пересечься, как автору поста, но могу с гордостью похвастаться, что прошел 3 разные эпохи вычислительной техники, от альфа-транслятора М-222 до современных PC архитектур.
разные методики тестирования, разное железо, разные тараканы в голове тестирующих…
зависит от кучи факторов, и результаты рознятся даже до 50%
например:
— выбор последовательного/рандомного чтения/записи (не знаю почему, но влияет)
— в одном соединении или на каждую команду — своё соединение
— кол-ва запущеных тестовых клиентов(потоков)
— длинна блока данных
— пушим данные в пустой редис или там уже понапихано 10М ключей
и мн. другое.
Во-вторых, видел бенчи редиса на commodity сервере в 300К RPS.
у меня более 20К rps не выходило…
сколько раз убеждаюсь, что НЕЛЬЗЯ ВЕРИТЬ ЧУЖИМ ТЕСТАМ
разные методики тестирования, разное железо, разные тараканы в голове тестирующих…
редис вполне можно использовать для хранения сессий, при том — это вполне нормальное и жизнеспособное решение.
Только надо помнить, что редис:
1) держит все данные в оперативной памяти и её может не хватать… тогда он лезет в своп и все начинает тормозить
2) синкует данные в бэдграундоввском процессе путем форка. Для этого нужно памяти еще ровно столько — сколько занимает сам редис, иначе форк будет неудачным. По этому, на одной машине с большим объемом памяти лучше развернуть кластер из трех и более экземпляров редиса.
Пример для понятия сути проблемы:
Пусть физический сервер имеет 16Гиг, тогда мы можем запустить:
один экземпляр редиса использующего не более 8 Гиг
два экземпляра редиса, использующего не более по 5.3 Гиг, общая используемая память 10.6 гиг
три экземпляра редиса, использующего не более по 4 Гиг, общая используемая память 12 гиг
шардирование редиса происходит на клиенте, это три строчки кода и не является проблемой.
согл, у нас хакер == взлом, у них hack высшее искусство кодинга
Высококвалифицированный ИТ-специалист, человек, который понимает тонкости работы программ ЭВМ.
Изначально хакерами называли программистов, которые исправляли ошибки в программном обеспечении каким-либо быстрым и далеко не всегда элегантным (в контексте используемых в программе стиля программирования и её общей структуры, дизайна интерфейсов) или профессиональным способом; слово hack пришло из лексикона хиппи, в русском языке есть идентичное жаргонное слово «врубаться» или «рубить в ...»
Wikipedia.org
меня в проекте 100М лайков и это не предел.
www.slideshare.net/akalend/kalendarev-bike-in-nosql
1) практика показывает, что на сайтах производителей тесты не всегда объективны и их лучше делать самому.
порой у меня тесты отличались на 50-250% процентов от заявленного,
все ИМХО зависит от методике тестирования и железа. По этому тесты делаем сами, а не ведемся на марткетинговые ходы.
2) что касается тарантула, то последние новости: в tarantool 1.6 в связи с переходом на FFI Lua производительность поднялась в от 20% до 800% и можно говорить о производительности от 1.2М до 5М (на разные виды операций)
3) Neo4j не единственная графовая БД :
Лично я за правильное ООП, где должен быть DataObject. И пусть в нем маппинг не автоматизированный, но он прозрачен для программиста и при необходимости данный маппинг можно правильно с оптимизировать, а не гадать на кофейной гущи ORM. И пусть такие товарищи, как Fesor сколь угодно кричат, что зло, а что добро, но я последние пять-семь лет больше занимаюсь переделыванием и оптимизацией чужого говнокода, про архитектуру которого и не задумывались, где можно было написать по уму, используя всего лишь треть нормальных запросов…
Бл. наболело. ;(
Серия Эльбрус» советских многопроцессорных суперкомпьютеров, разработанных в ЛИТМО (ныне ИТМиВТ) в 1970—1980-х годах, кластер на базе БЭСМ-6 (Большая Советская вычислительная машина).
Мой отец имел опыт разработок на этих компьютерах, были расчеты связанные с космическими технологиями. На сколько мне известно, но история замалчивает, что ЦРУ запустило дезинформацию о выгодности технологии IBM 360/370 и нашим правительством была закуплена через посредничество Франции технология производства IBM 360, Однако документации по математическому обеспечению не передали, на верху порешили, что не дураки и сами разберемся. В результате мы с десятилетнем опозданием запустили ЕС-совскую серию: ЕС 1022, ЕС 1033., тем самым закрыв инвестиции в технологию БЭСМ и Эльбрус. Этим политическим решением мы закрыли свои наработки и принялись осваивать уже на этом момент устаревшию ЕС-совскую серию в чем опоздали скорее всего уже навсегда.
Более менее нормальная литература по этой тематике появилась с десятилетним опозданием. Это были мои студенческие годы. Хитовой книгой моей юности была: Джермейн. «Программирование на IBM 360»…
Вся вышеизложенная информация — это лишь мнение моего отца, который был тесно связан с разными IT технологиями в космической индустрии.
В ходе моей студенческой жизни пришлось работать и в упомянутом в статье альфа-транслятором… Да, были интересные и увлекательные времена… К сожалению, со звездами IT индустрии мне не удалось пересечься, как автору поста, но могу с гордостью похвастаться, что прошел 3 разные эпохи вычислительной техники, от альфа-транслятора М-222 до современных PC архитектур.
какие используются библиотеки шифрования?
и в книге годовалые дети пытаются увеличить картинку разводя пальчиками… как на айфоне
монетизация за счет рекламы
и масштабирование из коробки — тоже через одно место сделано… Когда прижмёт — решардинг делать замучаетесь.
зависит от кучи факторов, и результаты рознятся даже до 50%
например:
— выбор последовательного/рандомного чтения/записи (не знаю почему, но влияет)
— в одном соединении или на каждую команду — своё соединение
— кол-ва запущеных тестовых клиентов(потоков)
— длинна блока данных
— пушим данные в пустой редис или там уже понапихано 10М ключей
и мн. другое.
у меня более 20К rps не выходило…
сколько раз убеждаюсь, что НЕЛЬЗЯ ВЕРИТЬ ЧУЖИМ ТЕСТАМ
разные методики тестирования, разное железо, разные тараканы в голове тестирующих…
редис вполне можно использовать для хранения сессий, при том — это вполне нормальное и жизнеспособное решение.
Только надо помнить, что редис:
1) держит все данные в оперативной памяти и её может не хватать… тогда он лезет в своп и все начинает тормозить
2) синкует данные в бэдграундоввском процессе путем форка. Для этого нужно памяти еще ровно столько — сколько занимает сам редис, иначе форк будет неудачным. По этому, на одной машине с большим объемом памяти лучше развернуть кластер из трех и более экземпляров редиса.
Пример для понятия сути проблемы:
Пусть физический сервер имеет 16Гиг, тогда мы можем запустить:
один экземпляр редиса использующего не более 8 Гиг
два экземпляра редиса, использующего не более по 5.3 Гиг, общая используемая память 10.6 гиг
три экземпляра редиса, использующего не более по 4 Гиг, общая используемая память 12 гиг
шардирование редиса происходит на клиенте, это три строчки кода и не является проблемой.
Надо точнее называть Вашу статью, например: «Решение проблемы сессий при масштабировании РНР прриложений»
проблема балансировки практически не раскрыта… в основном прописные истины
в целом, написано не плохо, продолжайте свой цикл, многим будет полезно.