Канал тут вообще не причем.
Как нативные так и html приложения примерно одинаково работают с данными через сеть, все что надо кешируется или обновляется очень редко.
Проблема только в тормозах и глюках javascript решений по отношению к нативным.
так лимиты то давно работают и я уже от этого страдаю.
как на статические карты — пользователям тупо отображается красный крестик.
так и на геокодирование (которого тоже нет в консоли)
хм…
а сейчас то как быть — статические карты давно уже с лимитом, причем узким (1000 запросов — это мало)
я бы и рад может его расширить и заплатить, но получается что никак
Все возможные роботизированные рекомендации — дело бесполезное.
Вот если бы можно было удобно записывать свои просмотренные фильмы, чтобы потом
на вопрос «Что посоветуешь посмотреть?» — достать быстро этот список (с того же телефона) и предложить сразу другу кучу вариантов.
Ну и в обратную сторону…
видели такие сервисы?
По-моему основной профит, который дает ВУЗ — это друзья и связи (твои одногрупники, соседи по общаге).
И чем сложнее ВУЗ, тем лучше. Так уж выходит, что твой социум тебя же держит на одном уровне с ним. И чем он выше в интеллектуальном и культурном плане, тем выше планку ты и для себя поднимаешь.
У нас postgres, сейчас 8 баз на 4 серверах с запасом в 3-4 раза.
Кластеризацию осуществляем через plproxy, делим данные по user_id равномерно.
В нагруженных таблицах где то по 20-40 мл записей.
Оптимистично мы ожидаем прирост пользователей через год на 200-500%.
Узким местом оказался plproxy, который помимо проблем с производительностью
добавил огромные сложности в разработке.
Сейчас избавляемся от plproxy, переводя всю логику в основной код (java)
Также рассматриваем частичный переход на noSQL
Ну вариант с диапазонами id понятен ( просто с какого то момента все новые пользователи
отправляются на новые сервера). Но в этом случае уже не будет равномерного красивого распределения данных. Или это нормальная практика?
как при шардинге базы добавляются новые сервера в кластер базы?
Если например у нас есть 3 сервера (3 базы), то при добавлении 4-го нам ведь надо все данные
с этих трех переворошить и распределить на 4 части (по новой хеш функции),
а это совсем нетривиальная задача при миллионах записей.
Подскажите пожалуйста — возможна ли а GAE реализация
запроса с упорядоченными элементами?
как аналог например такого запроса SQL: SELECT * FROM table ORDER BY id DESC LIMIT 10
При условии что в таблице более 1 мл записей
Да, иногда админ это делал насколько помню, но памяти на тот момент было вроде меньше 10г.
возможно сейчас (когда машины посильнее) мы и не заметили бы проблему.
Многие используют репликацию для распределения нагрузки как я вижу.
Но мы уперлись в размер таблицы — при достижении определенного размера (более 20 мл записей)
запросы проходят плохо, даже по основному ключу.
Потому было решено кластеризовать базу в целях уменьшения именно размера таблиц.
И как я понимаю репликация тут не поможет?
Используем для масштабирования pl proxy.
данные распределяются по нескольким серверам баз данных равномерно по id пользователя
Но уж больно много телодвижений требует такая схема и с трудом себе представляю момент когда нам потребуется увеличить число баз в 2-3 раза.
Кто какие решения использует для масштабирования postgres?
Как нативные так и html приложения примерно одинаково работают с данными через сеть, все что надо кешируется или обновляется очень редко.
Проблема только в тормозах и глюках javascript решений по отношению к нативным.
через build.phonegap.com под все платформы.
И это работает.
как на статические карты — пользователям тупо отображается красный крестик.
так и на геокодирование (которого тоже нет в консоли)
а сейчас то как быть — статические карты давно уже с лимитом, причем узким (1000 запросов — это мало)
я бы и рад может его расширить и заплатить, но получается что никак
И вообще нет никакой привязки аккаунта к картам, даже apiKey не используется же.
Вот если бы можно было удобно записывать свои просмотренные фильмы, чтобы потом
на вопрос «Что посоветуешь посмотреть?» — достать быстро этот список (с того же телефона) и предложить сразу другу кучу вариантов.
Ну и в обратную сторону…
видели такие сервисы?
И чем сложнее ВУЗ, тем лучше. Так уж выходит, что твой социум тебя же держит на одном уровне с ним. И чем он выше в интеллектуальном и культурном плане, тем выше планку ты и для себя поднимаешь.
Если мне нужно получать данные не по ключу, а по диапазону (дат),
как это реализуемо?
А то к вечеру на первое выйдем.
Кластеризацию осуществляем через plproxy, делим данные по user_id равномерно.
В нагруженных таблицах где то по 20-40 мл записей.
Оптимистично мы ожидаем прирост пользователей через год на 200-500%.
Узким местом оказался plproxy, который помимо проблем с производительностью
добавил огромные сложности в разработке.
Сейчас избавляемся от plproxy, переводя всю логику в основной код (java)
Также рассматриваем частичный переход на noSQL
отправляются на новые сервера). Но в этом случае уже не будет равномерного красивого распределения данных. Или это нормальная практика?
как при шардинге базы добавляются новые сервера в кластер базы?
Если например у нас есть 3 сервера (3 базы), то при добавлении 4-го нам ведь надо все данные
с этих трех переворошить и распределить на 4 части (по новой хеш функции),
а это совсем нетривиальная задача при миллионах записей.
XML-API было только у Мегафона и то вроде только питерского региона.
Не пойму почему до сих порт никто не сделает сервис с API получения баланса по всем операторам
— хотя бы платный, чтобы помочь куче людей?
запроса с упорядоченными элементами?
как аналог например такого запроса SQL: SELECT * FROM table ORDER BY id DESC LIMIT 10
При условии что в таблице более 1 мл записей
возможно сейчас (когда машины посильнее) мы и не заметили бы проблему.
Например c телефона (как это сделано в facebook/oAuth)
Но мы уперлись в размер таблицы — при достижении определенного размера (более 20 мл записей)
запросы проходят плохо, даже по основному ключу.
Потому было решено кластеризовать базу в целях уменьшения именно размера таблиц.
И как я понимаю репликация тут не поможет?
данные распределяются по нескольким серверам баз данных равномерно по id пользователя
Но уж больно много телодвижений требует такая схема и с трудом себе представляю момент когда нам потребуется увеличить число баз в 2-3 раза.
Кто какие решения использует для масштабирования postgres?