alekseyHunter

Примерно так, я полагаю?

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

Архитектура проектов не зависит от языков программирования, библиотек, баз данных.
Начинать надо с бизнес-требований, дальше переходим к бизнес-логике, а дальше уже работаем на уровне реализации (языки, библиотеки, фреймы и т.п).
+ еще архитектура штука изменчивая. Она должна и будет меняться при смене требований.

Посоветовать могу книгу «Чистая архитектура. Роберт Мартин». Что-то сразу не зайдет, но в целом станет легче)

Highload Channel
DotNext

https://habr.com/ru/users/sidristij/
https://habr.com/ru/company/jugru/blog/498932/

В качестве живых примеров highload проектов на dotnet можно брать StackOverflow/StackExchange, СКБ Контур, ДоДо Пицца, 2Gis

Блог про архитектуру StackOverflow/StackExchange

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

Примерно так:

$filters = array();
$values = array();

foreach(array("user_id","city","age","name") as $key) {
  if (isset($_GET[$key])) {
    $filters []= "$key = ?";
    $values []= $_GET[$key];
  }
}

$sth = $dbh->prepare("SELECT * FROM users WHERE ".implode(" AND ", $filters);
$sth->execute($values);

Тут для всех указанных запросов накапливаются условия фильтра и значения в два массива, один затем через AND используется в WHERE, а второй передаётся при выполнении запроса.

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

Продолжать учить Python и выучить Django. Совсем хорошо, если ещё овладеть NumPy и Pandas. Со всем этим добром активно искать вакансии, проходить собеседования, обязательно брать обратную связь, подтягивать то, из-за чего не взяли, повторять попытки.

Вполне себе любая развитая современная РСУБД годится для этой задачи.
MySQL, PostgreSQL...

А по мере роста нагрузки - тут не выбором СУБД нужно заморачиваться, а MQ-сервер ставить. Он гораздо легче сравиться с бешенными нагрузками.

Как вариант - Queue на базе Tarantool, например. Я даже не знаю что вы там должны такое сделать, чтобы заткнуть его производительность. При условии того, что на сервере достаточно много оперативной памяти.

Из самого критично подозрительного - полнотекстовый поиск.
Впрочем, полагаю, что полнотекстового поиска средствами MySQL или PostgreSQL вплоне хватит.

Если уж делать прям таки серьезный чат типа Slack, то для полнотекстового поиска я бы вообще отдельную специализированную БД держал бы. Например, SphinxSearch.

Но, для начала, возможностей PostgreSQL или MySQL будет вполне достаточно.

Что до Mongo... Если вам не нужна репликация без консистентности. Зато быстрая...
Так вот если вам не нужна такая репликация, то Монга вам не нужна.

РСУБД будут существенно быстрее.

Вот ежели вы планируете заводить ваш чат в кластер, когда одного сервера вам не хватит, то тут да, тут РСУБД не лучший выбор. Тут бы я рекомендовал как раз Монгу.
Но опять таки кластер серверов для чата вы без MQ не сделайте.

Вывод:

Начните с обычной РСУБД.
Как начнутся затыки - рассмотрите MQ
Как начнется рост до масштаба планеты - рассматрите Монгу.

Вся система работает с бд MySQL - InnoDB, сообщения пишутся в бд при каждой отправке (INSERT), пока сервис еще не запущен, сообщений мало (только мои тестовые) все работает шустро, но вот когда запущу и количество сообщений перевалит за несколько миллионов, что будет тогда с моей бд? Начнутся жесткие тормоза при select и insert?

Вам никто не мешает это проверить.
Сгенерируйте миллион случайных сообщений.

При грамотном использовании индексов - ровным счетом никаких проблем ни на миллионах ни на миллиардах записей.

SELECT Concat(calendar.name, " ", calendar.year) as name, ifnull(date.value1,0) AS value
 FROM (SELECT DISTINCT date.year, month.id, month.name FROM date, month) AS calendar
   LEFT JOIN date
     ON date.year = calendar.year AND date.month_id = calendar.id
 ORDER BY calendar.year, calendar.id LIMIT 6 OFFSET 18

ограничиваясь текущим месяцем … последние 6

SELECT Concat(calendar.name, " ", calendar.year) as name, ifnull(date.value1,0) AS value
 FROM (SELECT DISTINCT date.year, month.id, month.name FROM date, month) AS calendar
   LEFT JOIN date
     ON date.year = calendar.year AND date.month_id = calendar.id
  WHERE CONCAT(calendar.year, '-', LPAD( calendar.id, 2, '0')) 
                 > LEFT(DATE_SUB(NOW(), INTERVAL 6 MONTH), 7)
 ORDER BY calendar.year, calendar.id LIMIT 6

Рассуждения неверные. Читай код FragmentManager'a. Ни в одном из случаев объект не будет помечен, удалён, и тд. Ссылка на него останется в транзакции.

Нормы никакой нет. Есть требование - чем меньше памяти потребляет, тем лучше. В идеале - ноль

Медитировать на график потребления памяти в такой ситуации смысла особо нет. Используй LeakCanary для выявления утечек.

Что первое, что второе, по описанию, требуют WebGL. Второй вариант проще и легче в плане кода будет: статичная сфера с текстурой + текст, который описывает движение по её орбите.

Можно на CSS сделать достаточно убогую бесконечную прокрутку карты, но она не будет учитывать геометрию шара.

Типа так:


UPDATE. Увидел такой баг в Android Chrome в результате совместной работы border-radius и overflow:

Нашел решение хаком. Нужно добавить следующее к такому блоку:

-webkit-mask-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAIAAACQd1PeAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAA5JREFUeNpiYGBgAAgwAAAEAAGbA+oJAAAAAElFTkSuQmCC); /* this fixes the overflow:hidden in Chrome/Opera */

Это исправило проблему, обновил песочницу.

Есть смысл ставить один раз обработчик кликов на весь RecyclerView:
https://medium.com/@harivigneshjayapalan/android-r...

Ставить обработчики на каждый элемент списка — это перебор.