uptech

В правом нижнем угле, где и выбор языка . Далее просто сохраняешь.

Знаете, я с вами соглашусь, что хорошую вводную по Elastic трудно найти. Пока сам не переварил доков и не набил шишек многие элементарные понятия оставались для меня неясными. Поэтому вот моя вводная: Elastic можно использовать как NoSQL БД, только надо быть внимательным, т.к. всё-таки его основная задача поиск, а не удовлетворение функций БД. Например, если вы не настроили хранение исходных данных, а только индексацию, то свои данные вы уже не извлечёте из него. НИКОГДА. Только отдельные выражения, удовлетворяющие условиям поиска. Всё, тупик. Так же нельзя повторно индексировать уже загнанные в него данные. Т.е. перед загрузкой данных надо грамотно настроить индексацию, т.к. перестроить индекс, как это делается в реляционной БД невозможно. Нужно придумать новую схему индексации и перезалить данные в Elastic. Именно поэтому основное использование Elastic - как дополнение к существующей БД из которой данные можно перезалить по одному или полностью в Elastic (можно, конечно сделать схему Elastic->Elastic, но тоже есть нюансы).
Ещё пару слов про схему. Это ЛОЖЬ, что в Elastic нет схемы данных. Она как раз есть и ооочень жёсткая. Жёсткая до того, что однажды определив, вы не сможете её поменять. Изначально Elastic оказывает медвежью услугу, разрешая вам дополнять схему по-умолчанию, но когда вы разберётесь с этой темой, то можете обнаружить, что Elastic "понастроил" такого у себя внутри, что остаётся только охреневать и переделывать всё явно, отказавшись от его "услуг" по автоматическому добавлению полей в схему.
Так же в Elastic очень непросто строить сложные запросы на поиск и агрегатные запросы. Совершенно неинтуитивно. Но если освоитесь, то будет вам счастье. )))
Несмотря за такие "страшные" вещи - Elastic классная система и по производительности агрегатных запросов не уступает платной версии MSSQL в поиске в многопроцессорных системах (проверял на одинаковых аппаратных конфигурациях с 16 ядрами). Так что если вам хочется большую скорость в агрегатных запросах и главное - это бесплатность, то берите и осваивайте Elastic. Мощности и возможности у него огромные. Но... нужно потратить приличные усилия на изучение.

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

Классический пример разделения очередей:
- mailer - очередь для рассылки почтовых сообщения пользователям
- default - для всего остального

Можно сделать так что для очереди mailer вы запускаете 10 процессов (не воркеров, а именно процессов ОС), а для default только 1. Тем самым вы делаете приоритетной очередь mailer.
Распределением нагрузки можно также управлять с помощью "весов" (параметр -q mailer,9 default,1 ). В данном случае из 10 задач 9 будут взяты из очереди mailer и только одна из очереди default.

Под воркерами могут подразумеваться два понятия:
- воркер как процесс ОС который берет задачи из очередей на выполнение
- воркер как класс руби, который выполняет какую-то бизнес-задачу

В основном конечно же под воркерами подразумевается второй вариант.

По вашим вопросам:
- как воркеры исполняются?
Процесс-обработчик берет задачу из redis и выполняет её. Тут важно понимать, что при аварийном завершении работы процесса вы можете потерять задачу (такие кейсы бывают очень критичными для бизнеса).

- какой обьём памяти для этого нужен?
Объем данных в redis'е можно посмотреть в админском интерфейсе.

- почему redis

Кто знает...

- как это работает с redis
???

- почему в perform_async нельзя передовать сами обьекты? а только id, strings, json ...?
Можно, но не нужно. Все что попадает в perform_async должно попадать в redis. А это накладные расходы на хранение, сериализацию/десериализацию.

- Как правильно вызывать и добавлять очереди.
Что вы имели ввиду под "вызывать очереди"? Очереди добавляются автоматически
Вообще формат хранения можно запросто посмотреть в самом редисе.

Я более чем уверен, что ищут именно владельца с дефисом. Ибо на сайте без дефиса какая-то фигня вообще про пресс. А вот готовые домашние задания это уже экстемизъмом попахивает :D

Если коротко, то вот:

1. OpenShift
   
2. AppFog
   
3. AWS Elastic Beanstalk
   
4. Cloud 66
   

Если многословно и на английском, то: blog.sudobits.com/2013/02/15/heroku-alternatives-f...

P.S. От себя добавлю: не жалейте денег на Heroku. Сисадмин на поддержку серверов обойдется дороже. Нас счет за Хероку – порядка $900 в прошлом месяце, поэтому знаю о чем говорю. Пока не поднимется тысяч до 7-10, врядли задумаемся о собственных серверах – больше мороки с поддержкой этого зоопарка. Здесь же все проблемы решаются настолько оперативно, насколько это возможно. Есть специальные корпоративные тарифы (мы вот пока не доросли) с интересными плюшками для совместной работы. Да и создатель Руби у них работает, а уж он-то получше нас знает как рубин в продакшене держать :)