Геолокация большого количества постов на основе IP-адресов.(880 000 строк)

Question

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

У меня есть типичная база данных форума mysql, котораявключает в себя таблицу post с 880 000 строк.Таблица post содержит столбец для IP-адреса, и моей конечной целью является создание пузырьковой карты мира, основанной на геолокации каждого поста.Еще лучше, если я смогу разделять их по месяцам и создавать анимацию частоты сообщений по всему миру в течение последних 8 лет.

Поскольку это личный проект, и точность геолокации IP не важна, у меня былоисключить платные API, которые могут конвертировать IP в геолокацию.Я обнаружил различные вопросы о стековом потоке, которые связаны с веб-сайтом с базами данных IP-геолокации: https://dev.maxmind.com/geoip/geoip2/geolite2/

Первоначально я планировал загрузить эту базу данных на сервер форума и использовать мой опыт работы с mysql для создания новой таблицы.просто: postid, дата (как метка времени Unix), широта, долгота, город, страна.Затем экспортируйте эту таблицу в R и сгенерируйте все карты и диаграммы, которые я когда-либо мог захотеть.Тем не менее, база данных геолокации содержит более 3 миллионов строк в двух таблицах, и мой мертвый форум находится на простом плане общего хостинга, который не позволяет загружать данные.Я попробовал все решения в этих вопросах, но безуспешно: Как импортировать CSV-файл в таблицу MySQL доступ запрещен для загрузки данных в MySQL ЗАГРУЗИТЬ ДАННЫЕ INFILE в PHPmyadmin PHPMyAdmin: «Используемая команда недопустима в этой версии MySQL

Поэтому моей следующей идеей было экспортировать соответствующие столбцы из моей таблицы сообщений в .csv или .xml, а затем загрузитьте, на мой счет в iacademy3.oracle.com.Однако я не обладаю достаточным опытом работы с оракулом, и единственный известный мне метод - это интерфейс загрузки / выгрузки данных в мастерской данных.Не удалось загрузить XML-файл 177 МБ со следующей ошибкой:

ORA-31011: XML parsing failed ORA-19202: Error occurred in XML processing LPX-00222: error received from SAX callback function


Error loading XML.
Return to application.

. CSV-файл размером 34 МБ не удалось загрузить с двух попыток с этой ошибкой:

Failure of Web Server bridge:
No backend server available for connection: timed out after 10 seconds or idempotent set to OFF or method not idempotent.

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

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

Answer 1

Мы сгенерируем несколько IP-адресов, определим их местоположение и нанесем их на график:

library(iptools)
library(rgeolocate)
library(tidyverse)

Генерируем миллион (слишком равномерно распределенных) случайных адресов IPv4:

ips <- ip_random(1000000)

И,геолокация их:

system.time(
  rgeolocate::maxmind(
    ips, "~/Data/GeoLite2-City.mmdb", c("longitude", "latitude")
  ) -> xdf
)
##    user  system elapsed 
##   5.016   0.131   5.217 

5 с для 1 м IPv4.101

Теперь из-за однородности пузырьки будут глупо малы, поэтому просто для примера рассмотрим их немного:

xdf %>% 
  mutate(
    longitude = (longitude %/% 5) * 5,
    latitude = (latitude %/% 5) * 5
  ) %>%  
  count(longitude, latitude) -> pts

И нарисуйте их:

ggplot(pts) +
  geom_point(
    aes(longitude, latitude, size = n), 
    shape=21, fill = "steelblue", color = "white", stroke=0.25
  ) +
  ggalt::coord_proj("+proj=wintri") +
  ggthemes::theme_map() +
  theme(legend.justification = "center") +
  theme(legend.position = "bottom")

Вы можете видеть, что я имею в виду "слишком однородно".Но у вас есть «настоящие» IPv4s, поэтому вы должны быть gtg.

Подумайте об использовании scale_size_area(), но, честно говоря, не стоит вообще отображать IPv4s на географической карте.Я занимаюсь интернет-исследованиями, и требования к точности оставляют желать лучшего.По этой причине я редко опускаюсь ниже уровня страны (и мы платим за «реальные» данные).