search

citec-spbu / Spatial-Data-ETL

Автоматизация сбора и обработки пространственных данных
0 stars 0 forks source link

Изучить современные хранилища больших данных #19

Closed Kkhludneva closed 5 months ago

Kkhludneva commented 5 months ago

Познакомиться с современными практиками хранения больших данных. Рассмотреть нереляционные хранилища. Оценить, какой способ хранения оптимален для нашей задачи.

Отразить все рассуждения в комментариях под issue.

potomushozhenya commented 5 months ago
  1. https://books.google.ru/books?hl=ru&lr=&id=XjszEAAAQBAJ&oi=fnd&pg=PT17&dq=best+practices+big+data+database&ots=HXcrqVEpR6&sig=g-WJsSxkUv-waGAW_nFj6ajAtkI&redir_esc=y#v=onepage&q&f=true
  2. https://sci-hub.ru/10.3390/ijgi9050331
Guywash-Ka commented 5 months ago

PostgreSQL с PostGIS для геоданных OSM:

Преимущества:

  1. Продвинутая поддержка геоданных:

    • PostGIS предоставляет обширные возможности для работы с геоданными, включая создание геометрических и географических объектов, пространственные индексы, а также сложные пространственные запросы, такие как объединение, пересечение, вычисление расстояний и тд.

  2. Широкая экоcистема и инструменты:

    • Существует множество инструментов для импорта данных OSM в PostgreSQL/PostGIS, например, osm2pgsql, что делает процесс интеграции относительно простым и эффективным.

Недостатки:

  1. Горизонтальная масштабируемость:

    • Хотя PostgreSQL отлично масштабируется в вертикальном направлении, горизонтальное масштабирование может быть затруднительным. Это может стать проблемой при очень больших данных OSM или при высоких требованиях к отказоустойчивости.

  2. Сложность управления:

    • Полноценная реляционная СУБД требует более сложного управления, включая настройку, мониторинг и поддержку.

NoSQL:

Преимущества:

  1. Горизонтальное масштабирование:

    • NoSQL базы данных, такие как MongoDB или Cassandra, разработаны с учетом легкости горизонтального масштабирования, что может быть важно для обработки огромных объемов данных OSM и обеспечения высокой доступности.

  2. Гибкость схемы данных:

    • NoSQL системы позволяют просто модифицировать схему данных, что может быть полезно на этапах развития проекта, когда требования к данным могут изменяться.

Недостатки:

  1. Согласованность данных:

    • Во многих NoSQL системах приоритет отдается доступности и скорости, что может привести к проблемам с согласованностью данных.

  2. Ограниченная поддержка сложных запросов:

    • Сложные пространственные и геометрические операции, которые легко выполняются в PostGIS, могут быть не так просты или даже невозможны в некоторых NoSQL системах.

Итог:

NoSQL БД хорошо подходят для работы с большим количеством данных, но не так хорошо приспособлены для специфической работы с геоданными, с которыми очень хорошо умеет работать PostgreSQL. Оба варианта имеют права на существование, для реляционных БД это - PostrgreSQL, для нереляционных - MongoDB либо Cassandra, которая умеет обрабатывать большое количество запросов за короткое время.

potomushozhenya commented 5 months ago

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

sevryukov commented 5 months ago

@potomushozhenya @Kkhludneva @Guywash-Ka коллеги, я бы не считал эту задачу выполненной. Проблема не в решении, а в постановке. В постановке не уточняется, о каких данных идёт речь, что вкладывается в понятие "большие", и какие критерии оптимальности используются для отбора.

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

Если мы говорим о том, что нам необходимо решать задачи анализа именно пространственных данных, то да, важным критерием может стать поддержка пространственных типов. Однако приведённое сравнение конкретной СУБД (PostGIS) с широким классом СУБД (NoSQL) не даёт возможности сделать объективный выбор.

В своём сравнении авторы не делают ссылки на источники, что может говорить о самостоятельности этого сравнения. Если именно так всё и обстоит, то востребована методика сравнения.

Предлагаю ознакомиться со статьёй, которая может позволить несколько иначе рассмотреть возможности NoSQL СУБД в задачах хранения и обработки пространственных данных: Guo, D.; Onstein, E. State-of-the-Art Geospatial Information Processing in NoSQL Databases. ISPRS Int. J. Geo-Inf. 2020, 9, 331. https://doi.org/10.3390/ijgi9050331

Своим комментарием я не хотел авторов и команду отвлечь от мысли в последующем использовать PostGIS. Скорее хотел указать на некоторую недоработку в постановке задачи.

@nikita03565

nikita03565 commented 5 months ago

Не отменяя критического комментария Сергея Юрьевича, хочу похвалить ребят @Guywash-Ka и @potomushozhenya за приведенное сравнение подходов к хранению данных и аргументацию итогового выбора