Ми використовуємо Google AppEngine для запуску просторових запитів / атрибутів, і головна проблема (з першого дня) - як індексувати великі набори ліній / полігонів довільного розміру. Дані точок не надто складні (див. Геохаш, геомодель тощо), але набори випадково кластеризованих малих / великих багатокутників завжди були проблемою (а в деяких випадках все ще є)
Я спробував кілька різних версій просторової індексації на GAE, але більшість це лише два варіанти нижче. Жодна не була такою швидкою, як бази даних SQL, і всі мають плюси та мінуси. Хоча компроміси здаються розумними для більшості програм для картографування на базі Інтернету. Крім того, два нижче необхідно поєднати з відсікою геометрії пам'яті (через JTS тощо), щоб видалити будь-які функції, які не відповідають кінцевим параметрам пошуку. і нарешті, вони покладаються на особливості GAE, але я впевнений, що це можна застосувати до інших архітектур (або використовувати TyphoonAE для запуску на кластер Linux, ec2 тощо)
Сітки - упакуйте всі функції для певної області у відомий індекс сітки. Помістіть невеликий просторовий індекс у сітку, щоб ви швидко пересувались набором функцій, які він містить. Для більшості запитів вам потрібно буде лише отримати кілька сіток, які швидко, оскільки ви знаєте точну умову іменування сітки та як вона пов'язана з об'єктами K / V (отримує, а не запити)
Плюси - досить швидкий, простий у реалізації, без сліду пам’яті.
Мінуси - потрібна попередня обробка, користувачеві потрібно визначити розмір сітки, великі геоматеріали поділяються на декілька сіток, кластеризація може спричинити перевантаження мереж, проблеми з серіалізацією / десеріалізацією можуть бути проблемою (навіть коли стискаються через буфери протоколів)
QuadKeys - це поточна реалізація. в основному це те саме, що і Grids, за винятком того, що немає встановленого рівня сітки. як додаються функції, вони індексуються сіткою квадрокілька, яка повністю містить їх межі (або, в деяких випадках, розділяється на дві частини, коли не може бути використаний один квадратік, подумайте, що дателі). Після того, як qk буде знайдений, його розділяють на максимальну кількість менших qk, які забезпечують більш точне зображення зерна функції. вказівник / bbox на цю функцію потім упаковується у легкий gridindex (група функцій), який можна запитувати (оригінальний дизайн запитував функції безпосередньо, але це виявилося занадто повільно / CPU інтенсивно у випадках, коли набір результатів був великий)
Полілінійні квадратики http://www.arc2earth.com/images/help/GAE_QKS_1.png
Багатокутні багатокутники http://www.arc2earth.com/images/help/GAE_QKS_2.png
Конвенція про іменування чотиримісних кнопок, що використовується вище, добре відома, і що ще важливіше, має тенденцію до збереження місцевості (детальніше описано тут )
Полігон нагорі виглядає приблизно так: 0320101013123 03201010131212 03201010131213 0320101013132 0320101013133 03201010131302 03201010131303 032010101313002 032010101313003 032010101313012 032010101313013 03201010131312 03201010131312 03201010131312 032010101313
якщо межі запитів досить малі, ви можете безпосередньо отримати через qk. це оптимально, оскільки його єдиний, пакетний виклик RPC до даних GAE. якщо межі досить великі, що вона включала занадто багато можливих qks (> 1000), ви можете альтернативно запитувати за допомогою фільтра (наприклад: qk> = 0320101013 та qk <= 0320101013 + \ ufffd). Конвенція про іменування чотиримісних ключів плюс те, як рядки GAE індексує, дозволяє вищезазначеному запиту отримувати лише існуючі сітки, що опускаються нижче цього значення qk.
Є й інші застереження та проблеми, пов'язані з парфумерією, але в цілому його здатність проводити запити на квадратиках, що робить це здійсненним
приклади - запит на округи США: geojson
Плюси - досить швидко, без конфігурації розміру сітки, відсутності сліду пам’яті, немає переповнених сіток
Мінуси - необхідна попередня обробка, можливий перезавантаження в деяких сценаріях, відсутність полярних даних
Криві заповнення місця - Подивіться на розмови NextGen-запитів Альфреда в Google I / O цього року. Включення загальних кривих заповнення простору / часу разом з новими операторами MultiQuery (працює паралельно) дозволить отримати справді круті просторові запити. Чи обіграє це традиційна продуктивність SQL? Важко сказати, але він повинен дійсно добре масштабуватися. І ми швидко наближаємось до майбутнього, коли мобільні пристрої, що постійно перебувають на будь-якій формі / розмірі, різко збільшуватимуть трафік на ваш сайт / послугу.
Нарешті, я також погоджуюся, що вам слід дуже уважно ознайомитися зі своєю проблемою, перш ніж вибирати NoSQL через SQL. У нашому випадку мені дуже сподобалась модель ціноутворення GAE, тому вибору насправді не було, але якщо вам не потрібно масштабувати, заощадите собі час і просто використовуйте стандартний sql db