Лучшие практики моделирования Elasticsearch - PullRequest
Новая
       19

Лучшие практики моделирования Elasticsearch

0 голосов
/ 06 июня 2019

Я недавно начал работать с Elasticsearch и в настоящее время сохраняю некоторые данные в нем с помощью Spring Data Elasticsearch.

Я относительно новичок в базах данных NoSQL.

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

В настоящее время я вижу два подхода.

Первый - создать один документ для каждой записи журнала.

Что-то похожее на это 

@Document(indexName = "user_audit_log", type = "UserAuditLog")
public class UserAuditLog {

    @Id
    private String uuid;

    private Long userID;

    private String action;

    private String original;

    private String newValue;

    private OffsetDateTime timestamp;
}

И записать записи аналогичным образом в СУБД.Основное преимущество, которое я вижу в этом подходе, заключается в том, что нет необходимости беспокоиться о параллельности записи.

Второй подход - иметь один документ на пользователя.И записи журнала должны быть помещены в список внутри там.

Что-то похожее на это. 

public class UserAuditLogEntry {
    private String action;

    private String original;

    private String newValue;

    private OffsetDateTime timestamp;

}

@Document(indexName = "user_audit_log", type = "UserAuditLog")
public class UserAuditLog {

    @Id
    private Long userID;

    private List<UserAuditLogEntry> auditLogEntries;
}

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

Главный недостаток, о котором я могу подумать, - это необходимость одновременной защиты от записи.

Какая из них является наилучшей практикой вasticsearch?

1 Ответ

1 голос
/ 07 июня 2019

Не вопрос о масштабах переполнения стека (вы, вероятно, получите закрытые запросы).

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

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

И хотя настройка индексирования для вложенного объекта может работать, это намного сложнее, чем при использовании первого решения.

Так что просто сохраните отдельные записи в Elasticsearch, нет абсолютно никаких причин не делать этого.

И если вы хотите использовать модные информационные панели, такие как Kibana, это сразу же работает и с этим подходом.

...