2017-01-14 4 views
0

Так что в настоящее время у меня есть приложение, в котором я храню данные местоположения (lat, lng) вместе с другими полями, а кто нет. Так что я обожаю mysql или sql в целом, так это то, что я могу легко получить геопространственные запросы. например выберите все строки, которые попадают в заданный радиус и центральную точку.Использование DynamoDB с MySQL для запросов GeoSpatial

Что мне нравится в dynamodb, так это то, что он близок к бесконечно масштабируемому на AWS, который является сервисом, который я буду использовать и быстро. Я хотел бы переместить все мои данные на dynamodb и даже вставить новые данные. Но я не смог бы использовать эти геопространственные запросы, которые являются самой важной частью моего приложения. Это необходимо.

Я знаю о геобиблиотеке для dynamodb, но ее написано в java, а мой бэкэнд написан на php, поэтому нет необходимости, и они, похоже, не обновляют или не поддерживают эту библиотеку.

Одним из решений, о котором я думал, было сохранение только координат в mysql и сохранение соответствующего идентификатора вместе с другими данными (включая значения lat и long) в dynamodb.

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

Так что в основном я бы запросил все POI в пределах данного радиуса от mysql и со всеми идентификаторами, которые я использовал бы для получения всех результатов от dynamodb. Звучит сумасшедшим или что?

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

Так суммируют мои требования:

Должно быть на AWS

должны быть в состоянии выполнить геопространственных запросов

Должна быть возможность подключения к dynamodb и MySQL в PHP

Любая помощь или предложения были бы весьма признательны.

ответ

1

Мой инстинкт говорит, не используйте 2 источника данных, только если у вас действительно конкретный случай.

Сколько у вас данных? Действительно ли MySQL (или Aurora) не справляется с этим? Если ваше приложение читается тяжелым, оно может легко масштабироваться при чтении реплик.

У меня есть несколько идей для вас, которые могут приносит вам, по крайней мере немного ближе:

  1. Почему вы не реализовать свою собственную гео-библиотеку в PHP? : D
  2. Вы можете сделать фиктивный поиск в БД, где вы не фильтруете фактическое расстояние, но с верхней и нижней границей в лат. и долго. (Таким образом, вы не выполняете поиск по кругу, а по квадрату. Тогда на вас будет, если ваше приложение будет в порядке с ним или оно будет фильтровать результат, но это будет гораздо меньший набор данных и простой фильтр.
+0

Эй, Адам, данные пока не существуют, в приложении, которое является мобильным приложением при каждом открытии приложения, мы можем ожидать загрузки пользовательских данных с координатами. и мы можем почти гарантировать, что мы будем читать точки данных в пределах заданного радиуса. Все приложение основано на этом потоке. Я действительно думал о том, чтобы делать php-библиотеку, черт, даже быструю версию. но код был над моей головой. И мне не очень нравится идея использования фиктивного поиска. Почти все остальные данные будут в dynamodb. Это сложная проблема: (и я действительно хочу эту дешевую шкалу). –

+0

Aurora ... хорошая точка. Первоначально они не поддерживали их, но недавно объявили [поддержку пространственных индексов] (https://aws.amazon.com/blogs/aws/amazon-aurora-update-spaces-indexing-and-zero-downtime-patching /), хотя, с любопытством, они делали это с кривой заполнения пробела в индексе B-дерева вместо использования R-дерева как и MySQL, но пространственные функции одинаковы. Я не оценил производительность. –

+0

@AndrewEdwards все точки в пределах заданного радиуса являются легко вычисляемым подмножеством точек в минимальном ограничивающем прямоугольнике '(xr, yr) , (xr, y + r), (x + r, y + r), (x + r, yr) '. –

0

Возможно, CloudSearch может помочь вам. Он предлагает геопространственные запросы на длинных полях.Он хорошо работает вместе с DynamoDB, и у него есть PHP SDK (никогда не пробовал, хотя, я использую nodejs)

Вы пишете элементы, которые имеют lat, long fields для DynamoDB. Каждый элемент (или обновление/удаление элемента) автоматически загружается в CloudSearch через поток DynamoDB. Итак, теперь у вас есть «автоматические копии» ваших элементов DynamoDB в CloudSearch, и вы можете использовать все возможности CloudSearch для запросов, включая гео-запросы (одно ограничение, оно запрашивается только в блоках, а не в кругах, поэтому вам понадобится дополнительная математика)

Вам нужно будет создать поток DynamoDB, который запускает функцию Lambda, которая загружает каждый элемент в CloudSearch. Вы устанавливаете это один раз, и он будет делать свою магию «навсегда».

Этот подход будет работать, только если вы принимаете небольшую задержку между моментом, который вы пишете в DynamoDB, и в тот момент, когда он доступен в CloudSearch.

При таком подходе у вас все еще есть 2 источника данных, но они полностью отделены от перспективы вашего приложения. Один источник данных предназначен для запросов, а другой для записи. Их синхронизация выполняется автоматически для вас в облаке AWS. Ваше приложение записывается в DynamoDB и запросы от CloudSearch. И у вас есть преимущества масштабируемости, которые предлагают эти услуги AWS.

Смежные вопросы