Алексей Черемисин

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

Очень похоже, что поменялся алгоритм кеширования. Но у меня встречный вопрос, а почему бы не использовать ceph?! Ваша конфигурация как раз очень хорошо под это дело подходит, KVM/QEMU отлично работает с ceph напрямую. При этом вы получите практически моментальную миграцию виртуалок, очень гибкую работу с распределеенм хранилищем, снапшоты, бекапы, восстановление, клонирование, миграцию, забудете про lvm и raid, получите или быстрый кеш на ssd, или быстрый пул. В дополнение, практически неограниченно растущее хранилище данных и облачное хранилище, вылет одно любого сервера не скажется никак на доступности данных для виртуалок.

Из минусов - память на каждый терабайт дисков нужно гигабайт памяти, и нужна сеть 10гб между серверами.

Настройка не займет больше 30 минут и часа чтения документации. Диски не нужно делать в raid! На каждом из серверов достаточно отвести по 8-100 гигов для рутового раздела и загрузки, все остальное нужно просто отдать в ceph.

В любом случае вариантов как минимум два, или заглядывать вперед в потоке, или заново переоткрывать.
Можно поступить хитрым образом - использовать https://docs.oracle.com/javase/7/docs/api/java/io/... и/или GSON stream API.

В первом случае мы заглядываем в поток на какой-то размер, просматриваем его на наличии нужных нам маркеров, затем делаем unread и уже работаем как нам нужно.

Во втором случае можно прочитать только первый элемент, найти нужные нам маркеры и например переоткрыть файл заново - https://memorynotfound.com/gson-streaming-api-read...

На яве есть проект - apache tika tika.apache.org
Как раз для этих целей.
Вот здесь есть туториал https://www.tutorialspoint.com/tika/index.htm
Сама тика поддерживает парсинг текста и метаданных из приблизительно 15к разных форматов.

Все достаточно просто, перестаньте думать таблицами и начните думать ДОКУМЕНТАМИ.
У вас есть всего два документа - два индекса. Индекс Пользователей, и индекс Операций.
Пользователь представляет из себя документ со всеми полями таблицы member. А Операция, состоит из конкатенации полей member-operation-operationtype. Да данные в индексе Операции будут дублировать некоторые поля из Пользователей, но это и не страшно, это правильно, так как это фактически лог.

Скорее всего у вас проблема с определением скорости интерфейса. Ваш провайдер наверняка экономит на кабеле, и вместо 4-х пар дал две, да еще и на коммутаторе зарезал скорость типа 100Мб half dumplex. Вот некоторые карточки и ошибаются в определении автоматических параметров подключения.
У провайдера узнайте точные параметры подключения, и пропишите их через ethtool, и вставьте в настройки интерфейса.

env('ELASTICSEARCH_HOST', 'http://localhost:9200'),

Не?
И проверить, запущен ли elastic. Можно через curl

leah@xxx:~$ curl -XGET http://localhost:9200
{
  "name" : "DR4r-FT",
  "cluster_name" : "elasticsearch",
  "cluster_uuid" : "Q4TCatpdSkaMoqlezR-TQQ",
  "version" : {
    "number" : "5.1.1",
    "build_hash" : "5395e21",
    "build_date" : "2016-12-06T12:36:15.409Z",
    "build_snapshot" : false,
    "lucene_version" : "6.3.0"
  },
  "tagline" : "You Know, for Search"
}
leah@xxxx:~$

Странно, у меня для русских полей стоит russian аналайзер, из коробки, ищет по словоформам неплохо, но на фамилиях не тестировал. Попробуйте еще и fuzzy query.
Вот прямо сейчас проверил: "лебедь датчик", находит "Светильник Лебеди ночник с датчиком света Космос".
Ищу площадки, получаю "Серая площадка и круглая черн.ручка под замок"
Ищу лампа, находит и лампу и лампой и лампы, и лампа.
Ищу гвоздь, получаю Скоба пластиковая с гвоздем
PS. Elasticsearch 5.1.1 если чо. Специально никаких плагинов с русской морфологией не ставлю с версии 2.x

Витруализация - процесс, полностью эмулирующий "компьютер", с процессором, памятью, набором железа, от видеокарты, до жестких дисков. В виртаулизации мы полностью помещены в закрытый ящик, из которого теоретически ничего не торчит.
В случае полной виртуализации, устройства виртуальной машины полностью эмулируют работу оборудования, вплоть до регистров, памяти и т.д. В этом случае внетренняя программа практически не подозравает о какй-то подмене.

Паравиртуализация, тоже самое, что и в предыдущем случае, но некоторые компоненты, например сетевые или дисковые (и другие) устройства могут быть доступны напрямую через вызовы наружу виртуальной машины (с некоторыми оговорками). Для работы с паравиртуализированным оборудованием нужны отдельные драйверы и программные вызовы.

Паравиртуализация в общем случае работает быстрее, так как нет накладных расходов на ненужную эмуляцию.

Это в простом виде.

Полнейшая глупость! На данный момент: а по хорошему уже лет 10 минимум, существует куча асинхронных фреймворков и сетевых библиотек, которые работают ровно на том же самом принципе, как и nodejs.
Примеров, у нас их есть:
- фреймворки jooby.org, sparkjava, springboot
- библиотеки (серверы) netty, undertow, akka
По производительности ничуть не уступают nodejs.

Ну а как все это работает? Есть два вида программирования, которые можно совмещать:
Старый и много кем используемый
- сервер ждет сетевое соединение
- как только соединение произошло, сервер запускает процесс/поток и ему передает открытое соединение.
В этом случае мы ограничены количеством потоков/процессов в системе, имеем большой оверхед на создание процесса/потока. Зато нам не нужно сильно заботиться о работе с сокетами.
Новый хайповый/модерновый
- при старте в сервере региструются обработчики данных (наши сервисы/приложения)
- сервер открывает сокет и слушает все открытые им ранее сокеты, висит в ожидании события прихода/передачи данных на методе select/poll/epoll или побобном.
- как только сервер получил ответ, он вызывает зарегистрированный обработчик и передает туда порцию полученных данных, принимает эти данные обратно и и отправляет в сеть на нужное соединение
В этом случае сервер работает в один поток, просто последовательно вызывая обработчики и отдавая им данные. Быстро, очень быстро, ловко, нет накладных расходов. Зато, если какой обработчик пытается сделать блокирующую операцию - виснут все остальные обработчики, поэтому обработчики с сервером общаются сообщениями и стараются не занимать много процессорных ресурсов. Программирование получается сложное.

Также можно совмещать эти два подхода, делая и пул потоков и работая в асинхронном режиме.

На почитать сюда например - https://ru.wikipedia.org/wiki/Epoll

Посмотрите jooby.org, как замену springboot и springMVC. В Jooby и то и то органично совмещаются.

Меняем
for x in responsedata['data']:
на
for x in responsedata['data'][:30]:
Да и вообще, как-то так:

for item in responsedata['data'][:30]:
        for ph in item['SearchedWith']:
            print '%s:%s' % (ph['Phrase'], ph['Shows'])
            b = str(ph['Phrase'].encode('utf8'))
            c = str(ph['Shows'])

            # записываем в файл каждую фразу, полученную от Яндекса
            f.write(b + ':' + c + '\n')

Если под линуксом, то можно использовать биндинги к gstreamer.

А через virsh snapshot-XXXX пробовали? Правда у меня везде qcow2 или ceph :-)

snapshot-create Создать снимок на основе XML
snapshot-create-as Создать снимок на основе аргументов
snapshot-current Просмотр и изменение текущего снимка
snapshot-delete Удалить снимок домена
snapshot-dumpxml XML дампа снимка домена
snapshot-edit правка XML снимка
snapshot-info данные снимка
snapshot-list Показать снимки домена
snapshot-parent Get the name of the parent of a snapshot
snapshot-revert Восстановить домен из снимка

Ну: оно же черным по белому пишет, что не может распознать параметры с именами
[interval], [system_api_version], [system_id]
Проверьте или мапинг, или то, что посылаете.