German Zvonchuk

Если у вас 10 полей из 10 таблиц не влезают в память, то никак вы их не достанете без увеличения памяти для php.

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

Чтобы не значило ваше "передать" в данном случае.

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

2) Нужно иметь представление, как работает самый обычный способ получения контента - Curl. Попробуйте скопировать что то, поработать, представить в xml документ и тд. Тут вы определитесь с принципом работы парсера.
- парсер получает вводую информацию -> с учетом программы и вводных данных, парсер запрашивает определенные данные -> парсер обрабатывает данные для пользователя -> при необходимости, парсер повторяет запрос (инициированный пользователем или рекурсий) -> конец

3) Далее вы дойдете до механизмов защиты от парсинга:
- ограничение запросов на 1 ip, на один клиент и тд
- подгузка информации после загрузки контента
- дополнительный запрос на подгрузку контента с CSRF и другими способами
- блокирование ip
Это откроет вам парсеры типа PhantomJs, Научит пользоваться прокси, мимикрировать под популярные браузеры и тд.
Так же вы дойдете до многопоточности работы парсера, и подумаете о переходе на C и подобный язык программирования. Общаясь с сайтом уже посредством api.

А дальше, сталкиваяь с новыми проблемами, будете их решать.

Изучайте методы, которые давно отработаны для показа данных в различных картографических фреймворках для web.
Подходов несколько. Например, разбивать запрашиваемые данные на фрагменты одинакового (в проекции окна приложения) размера. Это позволяет не запрашивать те, которые у вас уже загружены. Можно запрашивать область больше вашего viewport-а (и комбинировать это с предыдущим методом). И делать новые запросы только тогда, когда величина scroll-а от точки предыдущего запроса превышает какое-то значение. Например, пользователь открыл карту, приложение запросило данные на покрытие viewport-а плюс 50% его ширины с каждой стороны. Пока пользователь не сдвинет карту дальше 25% ширины viewport-а от начальной точки, новых запросов не делать. Также можно озаботиться тем, чтобы сервер не пересчитывал всё каждый раз, а именно - сделать prerender для разных масштабных слоев. И использовать кэширование на стороне сервера. Или вообще превратить ваши маркеры в статичный (или закэшированный, условно статичный) растровый слой, а с сервером общаться только когда пользователь в маркер ткнёт, чтобы о нем информацию получить.

Давайте рассмотрим вопрос чуть поструктурнее.

Несанкционированное использование неофициальным клиентом - значит пытаемся защитить клиента.

Https с ключом к API защитит только от тривиального перехвата трафика сниффером (mitm).

Если расковыряют приложение и достанут идентификационный ключ для подписания запросов - будет проблема. Тут уже включаем защиту от «расковыривания». Имхо, лучший вариант - плановый выпуск обновления приложения с заменой ключа, и, возможно, внесением определенных изменений в хранение этого ключа (чтобы взлом клиента требовал определенного времени). Когда то народу надоест ломать.

Если ломать не надоело - то следует задуматься над причинами: почему кому то так хочется иметь неофициальный клиент к вашему api. Тут будет проще договорится - или продолжить играть в мечи и щиты.