Поэтому в настоящее время у меня есть приложение, в котором я храню данные о местоположении (lat, lng) вместе с другими полями, а кто нет. Так что в MySQL или sql мне нравится то, что я могу легко получать геопространственные запросы. например выберите все строки, которые попадают в данный радиус и центральную точку.
Что мне нравится в динамодебе, так это то, что он чертовски почти бесконечно масштабируется на AWS — сервисе, который я буду использовать, и быстрый. Я хотел бы перенести все свои данные в DynamoDB и даже вставить туда новые данные. Но я бы не смог использовать те геопространственные запросы, которые являются наиболее важной частью моего приложения. Это обязательно.
Я знаю о геобиблиотеке динамодаба, но она написана на Java, а мой бэкэнд написан на php, так что ничего не выйдет, плюс они, похоже, не обновляют и не поддерживают эту библиотеку.
Одним из решений, о котором я думал, было сохранение только координат в mysql и сохранение соответствующего идентификатора вместе с другими данными (включая значения lat и long) в DynamodB.
С этим я мог бы достичь желаемой функциональности геопространственных запросов, в то же время имея возможность хорошо масштабировать все на Amazon, потому что именно этот хост я использую.
Так что в основном я бы запрашивал все POI в пределах заданного радиуса из mysql и со всеми идентификаторами, которые я использовал бы для получения всех результатов из dynamicodb. Звучит безумно или как?
Но потенциальная обратная сторона этого заключается в том, что необходимо запросить один источник данных, а затем сразу же запросить другой, используя результат первого запроса. Может быть, я слишком много думаю и недооцениваю, насколько быстрыми стали эти технологии.
Итак, чтобы подвести итог моих требований:
Должен быть на AWS
Должен быть в состоянии выполнять геопространственные запросы
Должен быть в состоянии подключиться к DynamodB и MySQL в PHP
Любая помощь или предложения будут с благодарностью.
Мой инстинкт говорит: не используйте 2 источника данных, только если у вас действительно конкретный случай.
Сколько данных у вас есть? Разве MySQL (или Аврора) действительно не может справиться с этим? Если ваше приложение тяжело читается, оно может легко масштабироваться с помощью реплик чтения.
У меня есть несколько идей для вас, которые могут приблизить вас хотя бы немного ближе:
Может быть, CloudSearch может помочь вам. Он предлагает гео-пространственные запросы по длинным полям. Он хорошо работает вместе с DynamoDB и имеет PHP SDK (хотя никогда не пробовал, я использую nodejs)
Вы пишете элементы, которые имеют длинные, длинные поля в DynamoDB. Каждый элемент (или элемент обновления / удаления) автоматически загружается в CloudSearch через поток DynamoDB. Так что теперь у вас есть «автоматические копии» ваших элементов DynamoDB в CloudSearch, и вы можете использовать все возможности запросов CloudSearch, включая гео-запросы (одно ограничение, оно запрашивает только в прямоугольниках, а не в кругах, поэтому вам потребуется дополнительная математика)
Вам нужно будет создать поток DynamoDB, который запускает функцию Lambda, которая загружает каждый элемент в CloudSearch. Вы настроите это один раз, и он сделает свое волшебство «навсегда».
Этот подход будет работать, только если вы примете небольшую задержку между моментом, когда вы пишете в DynamoDB, и моментом, когда он доступен в CloudSearch.
При таком подходе у вас все еще есть 2 источника данных, но они полностью отделены от перспективы вашего приложения. Один источник данных предназначен для запросов, а другой — для записи. Синхронизация их выполняется автоматически в облаке AWS. Ваше приложение пишет в DynamoDB и запрашивает у CloudSearch. И у вас есть преимущества масштабируемости, которые предлагают эти сервисы AWS.