Оптимизированный способ хранения вложенных данных в Elasticsearch

Question

Мне было интересно, как лучше всего хранить объект данных в Elasti c, который выглядит примерно так:

physical_host_name: physicalOne
physical_host_cpu_model: x86_64
physical_host_cpu_num: 72
physical_host_mem_size: 792116312 KiB
physical_host_guests_list: 
{

    guestOne : 
    {
        guest_max_mem: 16384000 KiB
        guest_os_type: hvm
        guest_state: running
    }

    guestTwo : 
    {
        guest_max_mem: 11234000 KiB
        guest_os_type: hvm
        guest_state: paused
    }
}

Я бы хотел иметь возможность запроса по physical_host_name и получить все соответствующие данные для этого хоста (включая phys_host_ghest_list), а также иметь возможность запрашивать по guest_name (например, «guestOne») и получать соответствующие данные только для этого гостя.

Если это все в одном индексе? как должен выглядеть каждый документ?

Answer 1

Ваш дизайн - верный подход. Сам документ будет примерно таким же, как ваш пример, но JSON. Давайте назовем эту версию «А». Если какие-либо изменения происходят с хостом или гостем, вам нужно будет найти и обновить документ. Cosider использует полное доменное имя в качестве идентификатора документа. Это упростит CRUD. Но иметь сгенерированный elasti c идентификатор вполне приемлемо (и может быть лучшим подходом, если ваш набор данных достаточно велик для нескольких шардов, поскольку идентификатор влияет на распределение документов по нескольким шардам).

Я также вижу версию «B», где каждый гость является отдельным документом и содержит также ссылку на хост (родительский):

{ type:guest, name: vm_a, parent: physicalOne, cpu: {model: x86_64, num: 16} , mem: { total: 16384000 KiB} , os: {name: hvm, version: 10}, state: suspended }

И хост будет иметь собственный Документ, подобный следующему:

{type: host, name: physicalOne, parent: null, cpu: {model: x86_64, num: 72} , mem: {total: 792116312 KiB}, os: {name: linux, version: 3}, state: running} 

Если вам нужен заказ, для гостей или организаторов добавьте поле заказа, но я постараюсь использовать естественный порядок, используя имя хоста et c. Это значительно упростит добавление / удаление.

В таком случае вам нужно будет только обновить документ, в котором произошли изменения, добавить и удалить нового гостя просто. Обратите также внимание на вложенные свойства (cpu, os, ram). Это очистит ваши рисунки и, возможно, улучшит дизайн классов в приложении, которое использует / управляет этими данными. Этот дизайн также позволит вам делать запросы ко всем гостям или хостам. И основным преимуществом этого дизайна является одинаковый набор полей в хосте и гостевых документах, и это будет поддерживать как можно меньшую площадь (ОЗУ / хранилище) этого индекса.

Этот дизайн (B) - мой любимый, но только один из многих немыслимых. В конце концов, дизайн должен поддерживать вас во многих аспектах, но должен быть оптимизирован для чего-то вроде скорости / простоты чтения, письма, анализа и т. Д. c ...