mgyk

1) Проверьте engine в табличках -> InnoDB
2) Покажите настройки из my.cnf.
3) Посмотрите в process list нет ли пачки запросов висящих одновременно к таблице.
4) Покажите show create tabal XXX; для обоих таблиц и EXPLAIN этого запроса
На таких размерах все индексы должны помещаться в память и проблем быть не должно

Посмотрите внимательно на наличие Capfile в проекте. Руками перекладывать руби проект достаточно весело, так как нужно устанавливать зависимости и собирать и минифицировать фаилы

mongodb/elasticsearch
Проще структура, просто делаете набор атрибутов ( кол-во комнат, координаты, и т.д). Дальше в elasticsearch и оттуда вытаскиваете facet/aggregation. Можно вообще сразу данные в elasticsearch хранить, а не только индекс.

Лучше клонировать, или посмотрите в сторону докера, чтобы разворачивать все из одинакового образа. Иначе у вас будет единая точка отказа в виде NFS сервера, да и нагрузка будет приличной

Во-первых можно хранить ip как INT UNSIGNED и использовать inet_aton/inet_ntoa для конвертации. Во-вторых значительно быстрее будет использовать
INSERT INTO ... ON DUPLICATE KEY UPDATE views=VALUE(views)+views. Индекс при этом должнен быть UNIQUE INDEX(object, ip)

Если более правильно решать задачу, то просто поставьте гугл/яндекс аналитику на сайт и добавьте id материла в трекер. Таким образом получите нормальную статистику по материалам. https://developers.google.com/analytics/devguides/...

Попробуйте для начала mysql-tuning-primer запустить. Самые большие проблемы он должнен показать. И переходите на innodb сколько рамы не добавляй, но локи на таблицу все будут тормозить.

Я бы рекомендовал только mongodb или, если очень хочется усложнить себе жизнь, то простой redis/memcache. Во-первых couchdb это достаточно специфичное хранилище, для своего круга задач, только если вам очень нужны фичи кауча (двухсторонняя репликация, например). Во-вторых если вам нужно кэшировать mongodb возможно у вас не совсем подходящий дизайн хранилища. Так как для любого nosql хранилища структура данных должна учитывать и то, как эти данные потом читать оптимальный образом.

Если нужно дать доступ только в эту папку, то выставьте ее для пользователя как домашнюю и далее можно настроить sftp chroot. Юзер может иметь sftp доступ без возможности получения шелла на хосте.
https://wiki.archlinux.org/index.php/SFTP_chroot

Такой вариант корректный, но достаточно медленный

SET @rank=0; 
SET @current_field=0; 
select a.field_a, a.field_b, 
@rank:=if(@current_field = a.field_a,@rank+1,0) as rank, 
@current_field:=a.field_a as current 
FROM  (select field_a, field_b from test2 where field_a IN (1,2)  
ORDER BY  field_a, field_b DESC ) as a having rank < 3;

Посмотрите, возможно проще будет через GROUP_CONCAT(field_b ORDER BY field_b DESC) GROUP BY field_a и отфильтровать первые N на стороне клиента.

Можете посмотреть еще не jsonb в postgresql www.postgresql.org/docs/9.4/static/datatype-json.html если нужно индексировать json поля

Быстрее будет сделать LOAD DATA INFILE dev.mysql.com/doc/refman/5.1/en/load-data.html и импортировать сразу из CSV.
Можно попробовать engine=ARCHIVE если операция одноразовая. Будет больший шанс влезть в память при следующем GROUP BY

А через sftp работает?

Убедитесь, что у вас стоит индекс по двум полям сразу (job_id, worker_id => id_uslugi , id_rabotnik) Запрос на такой небольшой таблице должен выполняться достаточно быстро

SELECT c.name, b.name, count(*) from unslugi as a 
     left join info as b on a.job_id=b.id 
     left join info as c on a.worker_id=c.id 
WHERE a.usluga_okazana=1 
GROUP BY a.job_id, a.worker_id;

heroku config
Сделайте сначала и посмотрите, есть ли там эта ENV переменная. Вы же пытаетесь к локалхосту сконнектиться

Можете hosted ElasticSearch использовать https://bonsai.io/ если не хочется настраивать и поддерживать сервера с ним.

10% места может быть зарезервированно для root, но для mysql это место не доступно