Выбор MySQL или SQLite высоконагруженного проекта

#highload #sqlite #php #mysql

Здравствуйте! 
Подскажите, какую БД лучше выбрать(MySQL или SQLite) для высоконагруженного проекта
на PHP. Записей в таблице около 50. Обновление данных в них каждый час. Количество
заходов может доходить до 50к в день. 
Заранее спасибо!    

Ответы

Ответ 1

Начинать нужно с mysql и далее смотреть по обстановке. Расширять вы можете в глубь
или в ширину для подъема производительности.
Расширение в глубь - прикрутить в приложение кеширующий механизм, читать из которого
возможно гораздо быстрее.
Расширение в ширину - добавить еще один mysql-сервер. Производительность увеличится
чуть меньше чем в 2 раза.
Хотя с другой стороны 50 килозапросов в день = 35 в минуту = чуть меньше, чем 1 запрос
в 2 сек. mysql будет вполне справляться, это не нагрузка для одного таблицы в 50 записей.
Единственное, что наврятле они будут идти равномерно. ) 
В общем порядок действий такой: Ставим -> Тестим -> Изменяем/Добавляем -> Тестим
-> Изменяем/Добавляем -> Тестим -> Изменяем/Добавляем -> Тестим -> Изменяем/Добавляем
-> Тестим......... и так далее..


Ответ 2

MySQL + я бы посоветовал работу с базой через pdo только ради транзакций. Для высоконагруженных
проектов без транзакций некуда.


Ответ 3

Я использовал бы  MySQL.


Ответ 4

Недавно проводили сравнение Mysql с mariadb. Mariadb хорошо себя показала. А если
между Mysql и SQLite то естественно Mysql.)

MySQL vs PostgreSQL vs SQLite для высоконагруженных сайта на PHP?

#highload #sqlite #php #postgresql #mysql

Здравствуйте!

Подскажите, пожалуйста, какую БД выбрать(MySQL vs PostgreSQL vs SQLite) для высокоангруженного
сайта на PHP в котором будет примерно 300 000 статей, и 50 000-60 000 заходов на сайт
в день?
Спасибо!    

Ответы

Ответ 1

Ну для больших проектов SQLite точно не стоит выбирать. А что касается MySQL и PostgreSQL,
то это скорее зависит от собственных предпочтений и кривизны рук)) Несколько интересных
ссылок:

PostgreSQL vs MySQL: есть тесты на больших таблицах?
PostgreSQL vs MySQL vs ... 
MySQL vs PostgreSQL


Ответ 2

PostgreSQL выглядит более предпочтительнее по ряду причин:


Более "умный" планировщик запросов.
Возможность использования нескольких индексов на одной таблице (MySQL может использовать
только один индекс на одну таблицу).
Функциональные индексы (индексы по выражению, а не по данным из столбца).


Ответ 3

Для высоких нагрузок - postgresql
Кроме того, что тут написали


1)Много типов индексов
функциональные, частичные;
Триграмные индексы для запросов к тексту WHERE LIKE '%any%template%'(кому 
надо искать по шаблону, например в табличке с 10-20 миллионов строк - 
оценят),запросов,неточный поиск итд;
Если надо - крутой полнотекст(кому надо было его использовать на транзакциях
 в  mysql -  оценят);
География;
индексация внутренней структуры jsonb для быстрого поиска;
методы индексирования gist\gin\btree а будут и ещё 
2) полно всяких фишек для генерации отчётов на стороне SQL
   рекурсивные и обычные табличные выражения;
   аналитические функции;
   pivot(дополнение),unnest,generate_series,rollup и т.п.;
3)Очень много типов и крутые возможности контроля целостности по ним,
  например, задача бронирования номеров\мест на диапазон дат решается в лоб
  даже без триггеров и хранимок, чисто констрейнами.
4)фишки для скорости и для интерактива
   функционал для организации очередей массового обслуживания;
   система очень быстрых сообщений между клиентами;
   unlogged таблицы ;
   матвьюхи
5) средства для отказоустойчивости
     репликация из коробки;
     различные методы резервного копирования;
     мониторинг;
6)удобства для проггера 
   богатый pl\pgsql;
   можно писать на чём хочешь, хоть на plr,питоне и джаваскрипте;
   чеки,ключи;
   можно писать запросы не на sql, а прямо на языке хранимок, какой выберешь.

Ограничить пользователей ресурсами

#highload #производительность #limits #linux

Есть linux, пользователи пользуются ресурсами данной машины. Но делают это, не понимая,
что сервер один на всех )) и грузят его максимально тем самым мешая друг другу.Дано:
Виртуалка CentOS6.3 x64, 4GB RAMВот имею примерно такой вывод atop по самым пожирателям.NPROCS
  SYSCPU    USRCPU   VSIZE    RSIZE   RDDSK    WRDSK  RNET   SNET   CPU  RUID 1/155
   0.05s     1.88s   14.6G   877.6M      0K       0K     ?      ?   39%   user156 
  0.06s     0.45s   12.8G   603.1M      0K      32K     ?      ?   19%   user257  
 0.01s     0.04s   12.0G   594.8M      0K      24K     ?      ?   11%   user3 3   
0.00s     0.00s  401.9M    6632K      0K       0K     ?      ?    0%   user4Хочу в
/etc/sucurity/limits.conf зарезать немного их аппетиты, но пока выходит не очень.хочу
кол-во процессов на юзера сделать soft/hard - 50/65, уменьшить значение VSIZE (virtual
memory?), RSIZE (real memory?), и чтобы не жрали USRCPU (значение задается в минутах,
т.е. как я понимаю сейчас значение 1.88s = это 1 минута 88сек??? а почему не 2.28s
в любом случае процессор надо лимитировать)Все пользователи входят в группу @domainusers,
при попытке дать лимиты этой группе понял что это неверно т.к. все лимиты делятся пропорционально
на зашедших в систему юзеров и в итоге хватает ресурсов только на одного.. ))Остается
только пологинно перечислять всех в limits.confuser1  soft         nproc   50user1
 hard         nproc   65user1  soft         cpu     1user1  hard         cpu     2user1
 soft         as   1500000user1  hard         as   2000000user1  soft         rss 
400000user1  hard         rss  500000....user2 ....p.s. "as" как говорит (гугл) это
и есть виртуальная памятьВсе ли я верно делаю?P.S. эксперименты с limits.conf не внушают
мне надежды. Когда лимиты подходят к своему пределу система становиться нестабильна
и доходит до выпадания в корку. К примеру тупо не хватает свободных процессов, чтобы
открыть вкладку и, к примеру, браузер рушиться в этот момент какая-нибудь дебаг-тулуза
хочет отправить отчет и тоже валится и все крайне нестабильно начинает существовать.P.P.S.
Начал разбирать тему с cgroups/cgrules - этот механизм вроде более жизнеспособен.    

Ответы

Ответ 1

Вариант: PAM и его limits.conf


Ответ 2

cgroup самый правильный и скорее всего единственный инструмент в linux-e для этого

Грамотное кэширование в NodeJS проекте

#nodejs #кэширование #redis #highload

Планируется highload-проект с использованием NodeJS, MySQL, Redis, NGINX.
За основу взят nodejs фреймворк express, и для работы с сокетами (может это и не
хорошее решение) - socket.io. Проект представляет собой single page application, предполагается,
что сокет-соединение будет открыто повсеместно. Будет большое количество страниц, которые
являются статистично-информативными, и не щадят бд тяжелыми запросами.

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


Например, есть запрос к БД, его результат мы можем сохранить в Redis в виде JSON,
при следующих обращениях уже будем брать его из Redis и, когда необходимо - делать
инвалидацию данного кэша. - Насколько правильно это? И стоит ли именно в JSON хранить
данные?
Нам иногда нужна закэшированная страница не только в JSON, а кусок или целиком HTML.
- Правильно ли хранить эти куски в Redis?
Есть идея реализовать session-storage в Redis, как это сделать правильно? например
ключом будет id сессии, а значением - массив данных о клиенте. - Это правильно или
нет? Как будет лучше?
В каких случаях стоит записывать кэш в файлы на диск?
Стоит ли вообще пихать все что выше описано в redis? 


Я не имею опыта в highload, поэтому мне интересно все, что вы скажете, очень нужны
грамотные советы в построении проекта на перечисленных компонентах. Может, есть какие-то
рекомендации по работе с сокетами в highload, либо еще что-то, что касается основ такого
проекта. 

Признателен за ваши полезные советы, благодарю за внимание!
    

Ответы

Ответ 1

Например, есть запрос к БД, его результат мы можем сохранить в Redis в виде JSON,
при следующих обращениях уже будем брать его из Redis и, когда необходимо - делать
инвалидацию данного кэша. - Насколько правильно это?


На сто процентов, но своевременная инвалидация кэша - довольно большой челлендж.


  И стоит ли именно в JSON хранить данные?


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


  Нам иногда нужна закэшированная страница не только в JSON, а кусок или целиком
HTML. - Правильно ли хранить эти куски в Redis?


Нет, у вас же SPA, весь рендеринг должен быть на клиенте.


  Есть идея реализовать session-storage в Redis, как это сделать правильно? например
ключом будет id сессии, а значением - массив данных о клиенте. - Это правильно или
нет? Как будет лучше?


Если сессия у вас считается за постоянное хранилище, то неправильно, потому что Redis
не предназначен для постоянного хранения данных (хоть и умеет время от времени скидывать
данные на диск). Вместо этого лучше организовать двухуровневое (или даже трехуровневое)
хранилище из связки Redis - БД (In-Memory - Redis - БД в случае трехуровневой связки).


  В каких случаях стоит записывать кэш в файлы на диск?


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


  Стоит ли вообще пихать все что выше описано в redis?


Чем больше будет висеть в кэше, тем лучше, но время от времени посматривайте на количество
съедаемой оперативной памяти.


  Может, есть какие-то рекомендации по работе с сокетами в highload, либо еще что-то,
что касается основ такого проекта.


Помните про две вещи


Проект обязан масштабироваться горизонтально, т.е. простым добавлением новых серверов.
Из этого вытекает, что изменения на одном сервере должны быть видны для всех остальных
(это достигается за счет использования одного Redis и БД)
Существует такая штука, как dogpile effect, который означает кучу пользователей,
одновременно запросивших один и тот же ресурс. В случае с вышеописанным трехуровневым
хранилищем сто синхронно пришедших пользователей не обнаружат запись в кэше и ломанутся
(все сто) к БД. В случае, если в БД 20 одновременных подключений, и каждый запрос занимает
30мс, то последний пользователь получит данные не раньше, чем через 150мс (это в идеальном
случае, на самом деле там будет значительно большее число), что очень нехорошо.

Как эффективнее всего распарсить огромный файл логов на слабой машине?

#алгоритм #файлы #логирование #highload #big_data

Есть сервер с 1gb RAM. Есть лог файл nginx (любой другой веб-сервер) на 70gb. Как
максимально быстро собрать статистику по user agent пользователей сайта, учитывая описанные
ограничения по ресурсам.
    

Ответы

Ответ 1

можно воспользоваться StringTokenizer в языке Java, который позволяет считывать файл
построчно и не тратить память на хранение всех строк файла.

StringTokenizer tok = new StringTokenizer("/path/to/file");
while (tok.hasMoreTokens()) {
    String line = tok.nextToken();
    // работаешь со строкой.
}


Также можно указывать разделитель в конструкторе, по умолчанию стоит \t\n\r\f


Ответ 2

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

5k сообщений в секунду через один сокет

#highload #сокет #cpp

Доброго времени суток!
Есть некоторое приложение, обрабатывающее данные. К нему приходит клиент/клиенты
и начинают активно слать данные. В среднем на одной ноде должно обрабатываться 5-10к
сообщений в секунду от одного клиента. Средний размер сообщения 700-1100 байт. 
Сталкивались с проблемами переполнения буферов сокета, увеличили. Все равно скорости
не всегда хватает. выше 3к начинает проседать сервер и жрать 100% ( 1 ядра ).
Вопрос: как лучше организовать архитектуру и кто сталкивался с такими вещами? куда
посмотреть? почитать?
P.S. естесственно сервер и клиент linux.    

Ответы

Ответ 1

Если мощности есть - типичное количество одновременно подключённых клиентов существенно
меньше, чем количество ядер, то можно сделать, например, так. 
Поток, работающий с сокетом, вычитывает данные и кладёт их в очередь задач. Несколько
других потоков выбирают из этой очереди, обрабатывают эти данные и кладут результаты
в очередь результатов. Первый поток берёт всё из очереди результатов и отправляет клиенту.
Всё это реализовывать надо аккуратно, иначе будут проблемы с блокировками, конфликты
доступа к памяти... Нотификации о появлении новых данных - семафорами. Если будет тормозить
из-за них, можно заморочиться с ручной реализацией через переменные (будет сложно и
муторно, но слышал о подобной success story от коллеги).
Или, в качестве фантазии, можно сделать по очереди заданий на каждый поток-обработчик.
Каждый поток, работающий с сокетом, знает 4 потока-обработчика (4 проистекает из 10000/3000),
и по очереди кладёт им задания.
Но для начала я бы рекомендовал подумать над оптимизацией собственно процесса обработки.
Гораздо приятней было бы запихнуть всю обработку данных одного клиента на одно ядро.

Архитектура ВКонтакте

#highload #вконтакте

В наше время я думаю многих разработчиков интересует какая-либо информация по разработке
высоконагруженных (highload) веб-приложений — ВКонтакте отличный пример.
Наверное самое простое:

как работает распределение нагрузки? Вот например, домен vk.com в секунду получает
~100 000 запросов. (Наверное, обычный VPS не выдержит все-таки. :D) Так что дальше?
Как это работает?
как работают новости? Слышал про Dklab_Realplexor

Вопросы буду пополнять.    

Ответы

Ответ 1

Архитектура Вконтакте.


Ответ 2

Олег Бунин  оказал влияние на архитектуру Вконтакте. Послушайте подскасты, читайте
про него или вообще посещайте семинары где он выступает. Некоторые вопросы он затрагивает.
Суется почти на все семинары, рассказывает часто про вк. Так же можно ему лично задать
вопрос (помню вопросов к нему обычно не много, поэтому имеет смысл)


Ответ 3

Наверное, обычный VPS не выдержит
все-таки. :D

XDD) ИМХО первым что должно было прийти в голову это собственный ЦОД раз два, но
никак убогий VPS) Можно погуглить и собрать больше информации из недр чем из ответов
и комментов в этом топике!

Постобработка данных: фронтент или бэкэнд. За и Против

#http #архитектура #frontend #backend #highload

По сети передаются данные, которые представляют собой полигоны  (для простоты можно
считать, что это массивы float). В таком случае возникает вопрос, где лучше формировать
окончательный вид этих данных в виде json: на сервере и передавать json или на фронте.
Важное замечание. На фронте нужны именно json.

Кажется, что это лучше делать на фронте, чтобы не таскать по сети строки, а передавать
массивы float. Но я не уверен в производительности JS. Насколько эффективно раскладывать
всё по строкам?



Участники, которые собираются участвовать в конкурсе, обратите внимание, конкурс
объявлен для того, чтобы люди поделились своим опытом решения подобного рода задач.
Описание конкурса:

**В ходе беседы с участниками сообщества, выяснилось, что данная тема актуальна и
может быть интересна. В связи с этим, хочется получить в качестве ответа максимально
подробный ответ с описанием деталей задачи, которую Вы решали, а также принятое решение. **

Я, в частности, подразумеваю, что речь идёт о High Load, т.е. о системах, которые
обеспечивают безотказную работоспособность для не менее чем Q запросов и отвечают не
более чем за указанный интервал времени T

Меня интересуют решения T == 1 sek. Q >= 50. Лучше, больше 100
    

Ответы

Ответ 1

Вопрос, на самом деле, весьма сложный. Есть плюсы и минусы обоих решений.


Если делать всё на серваке, то все клиенты будут однородные данные получать и не
будет дополнительно обработки. Следовательно, шанс, что на клиенте накосячат, меньше.
Лишняя нагрузка на сервак. Порой переложить дополнительную обработку на клиент -
вполне валидное решение, чтоб снизить нагрузку.


Как пример, на текущем месте работы у нас используются карты. Необходима кластеризация
точек. И проблема с тем, где это делать (на сервере или клиенте), стоит весьма остро.
В базе миллионы пользователей, у каждого свои атрибуты (координаты, город, страна,
пол и т.п). Нужно кластеризовать всё это дело с учётом атрибутов.

Раньше на серваке захардкожено было, что больше определённого числа юзеров не выдаётся.



Встал вопрос о кластеризации. Варианта два:


Сервер отдаёт кучу пользователей. А клиентские приложения сами кластеризуют как-то
(iOS, Android и т.д. реализуют это на клиенте).
Кластеризовать на сервере. Клиентам только зум передавать.


Сервак, в принципе, неплохо масштабируется. Решили делать там. У нас бэк на ноде.
Используем supercluster, который подтягивает данные из базы и кластеризует всё. В риалтайме
вполне справляется с этим делом. Для того, чтоб не проседало ничего, используем Worker
Threads.

Из нашего проекта не могу скринов отсыпать, но выглядит как-то так:



P.S. у нас всё API гоняется в json. Если у вас не слишком частые запросы, то лучше
уж json использовать, оверхедом по размеру можно принебречь.


Ответ 2

Лучше фронту всегда отдавать готовые, потребительские данные. Всю остальную логику
с данными делать на сервере. Фронт у тебя должен быть "тупой". Получил данные и отобразил.

Лучше это в том числе потому что средний пользователь сегодня смотрит сайт не с десктопа,
а с телефона. Часто это не топовый iPhone, а какой-то слабый и дешевый андроид. На
нём всё медленно. Значит, чем меньше вы делаете ненужной работы на клиенте, тем быстрее
работает сайт у пользователей, и тем более удовлетворены работой вашего сайта его гости.
Это особенно важно если говорить не о сайтах уровня домашней страницы, а о настоящем
Highload: потеря одного процента пользователей из-за того что ваш сайт недостаточно
отзывчив может иметь очень ощутимые финансовые последствия.


Ответ 3

Тут вопрос не до конца поставлен...

Я считаю что в этом случае решения по архитектуре нужно принимать исходя из количества
передаваемых(обновляемых во времени) данных

Т.к. не понятно можно все сразу загрузить, сложить в Indexeddb и потом её кошмарить,
что весьма простое решение. 

Или же надо постоянно слать гео запросы на сервер, типа покажи мне что сейчас попало
в такой-то bbox, т.к. фич терабайты или они меняются постоянно.

И еше не понятно, вы решаете задачу оптимизации, или просто пока рисуете на карте ?

Я по работе в основном имею дело с компьютерной графикой и гео-информационными системами. 

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

Сырых данных вагон и маленькая тележка, однако то, что прилетает непосредственно
ко мне можно сказать песчинка. Бэкэнд у нас сложная штука- зоорпарк разного программного
и аппаратного барахла, раскиданного по планете, передачей данных в системе является
amqp брокер, и естественно он помимо моих данных обрабатывает еще кучу других потребителей
и поставщиков сообщений. При таком распределении нагрузки - я сам восстанавливаю пакеты
протобафа в geojson и тому подобные вещи на лету, ибо разным потребителям информация
нужна все-равно в разном виде и гонять по сети/спутнику лишние байты тоже не хочется,
еще нужно учесть что все это еще и дуплицируется по какой-то кучерявой логике детали
которой мне неизвестны =)

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

Что касается кластеризации и геоданных - вы смотрели в сторону postgis? Это посгрес
на стероидах, специально для geospatial данных и запросов


Ответ 4

Успешная практика разработки Unix говорит о том, что для связи компонент системы
 желательно (всюду, где это не является невозможным по тем или иным причинам) использовать
текстовые (с возможностью чтения и редактирования человеком) форматы представления данных.

Думаю, в вашем случае нужно гонять по сети json (т.е. человекочитаемый текст).

Горизонтальное масштабирование

#php #yii #mongodb #highload #масштабирование

Для одного из PHP + MongoDB проектов возникла необходимость осуществления горизонтального
масштабирования.


Учитывая, что будет использоваться несколько серверов, как лучше реализовать актуальность
своих же скриптов? Разные мелочи появляются довольно часто, как бы их из одного централизованного
хранилища сразу везде обновлять? sshfs, или gluster, или есть более простые способы?
В идеале хотелось бы иметь где-то директорию с ядром проекта, которое бы использовалось
напрямую остальными серверами.
Кэширование сейчас организовано в файловой системе, но, как я понимаю, будет необходимо
делать его общим для всех серверов. Как это делать лучше? Завести ещё одну БД под кэш,
или как-то ещё "выкручиваться"? Особенность у нас - в кэше есть данные общим объёмом
в несколько гигабайт, которые изменяются от силы раз в год, а используются чуть ли
не каждую минуту, именно из-за этого когда-то кэш не стали делать в redis. Как с такими
данными быть, тоже в БД? И какую БД для этого выбрать?
Правильно ли я понимаю, что при горизонтальном масштабировании сессии тоже 
необходимо хранить в БД?

    

Ответы

Ответ 1

Использовать сетевое хранилище для исходников - не самая лучшая идея. Каждый раз
когда появляются разные мелочи - они должны пройти тестирование в отдельном окружении
и только после этого следует использовать скрипт развертывания (deployment) актуальной
версии и только на одном сервере, - после чего при помощи a/b-тестирования убедиться,
что все работает как нужно. И только после того как все изменения протестированы, -
запускать скрипт развертывания на остальных серверах.
Использование файлового хранилища для исходников возможно, но это выглядит как неоправданная
жертва стабильности в угоду удобству.
Чем не подошел кэш в redis? - Несколько ГБ данных не создаст для него проблемы. Или
вы имеете в виду, что одна запись в кэшэ занимает несколько ГБ ? - В таком случае следует
разделить легкий и тяжелый кэш на раздельные сервисы.
Нет. При горизонтальном масштабировании вы можете привязать пользователя к определенному
серверу с которым он будет работать, в частности это используется для a/b-тестирования.
В любом случае хранить сессии в реляционной БД не нужно, - они очень хорошо лежат в
memcached.

База данных для статистических данных

#база_данных #nosql #highload #статистика #big_data

Есть набор быстро пополняющихся данных из большого количества источников, которые
тоже пополняются. Структура предельно простая:


id источника
значение
дата/время


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


Какая база данных лучше всего вписывается в эту задачу и почему?
Подойдут ли облачные NOSQL хранилища (Google, Amazon, Azure), или дешевле поднять
свой сервер с БД из ответа №1?

    

Ответы

Ответ 1

ИМХО. NoSQL - не подойдут от слова "вааще". Они заточены по совсем другой, более
"вариабельный" тип данных. При вашей простой структуре вам нужна именно реляционная
база данных, так как данные из большого количества источников - то что то серверное:
MSSQL, MySQL, Oracl - скорее всего любая из них справится.


Ответ 2

Если у вас данных ОЧЕНЬ много (сотни гигабайт-терабайты/день), то посмотрите на Hadoop,
там можно хранить много и считать быстро. 
Если же данных меньше - то стоит использовать PostgreSQL, Oracle, MS SQL.
NoSQL - это не о том, он скорее о слабо структурированных данных, так что в вашем
случае это просто не нужно.

Как интерпретировать понятие “высоконагруженное Android приложение”?

#android #highload #задание_на_собеседовании

На одном собеседовании на позицию Android developer мне был задан вопрос: "Имею ли
я опыт создания высоконагруженных Android приложений." (Жаль, что мысль уточнить определение
этого понятия мне пришла уже после собеседования)

Разработкой приложений для Android я занимаюсь уже несколько лет. Так получилось,
что проекты с которыми я работаю(л) не имели большого успеха в плане количества пользователей.
Исходя из этого, на вышеупомянутый вопрос я ответил, что такого опыта не имел, все
проекты доростали в лучшем случае до нескольки тысяч пользователей. (В данном случае,
я интерпретировал highload как количество активных пользователей)

Ранее я не встречал применение понятия "высоконагруженный" (highload) в контексте
Android приложений. И сейчас, задавшись вопросом я вижу, что это понятие применяется
по отношению к бекенду и сайтам.

После проведения аналогий с highload в вебе, я бы сказал, что highload Android app
- это приложение архитектура которого будет легко поддерживать внедрение новых функций,
оптимально расходовать ресурсы Android девайса. Но разве не каждое приложение должно
разрабатываться с учетом этих требований?

Хочу поинтересоваться у других специалистов, как вы понимаете "высоконагруженный"
(hihgload) по отношению к Android приложению?
    

Ответы

Ответ 1

Сложно сказать, что именно имели в виду на собеседовании, но я могу предположить
следующие ситуации:


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


И если с первыми 2 случаями все относительно понятно, то в последнем варианте можно
подумать о:


Отзывчивости и плавности приложения, особенно когда оно обвешано сторонними модулями
и библиотеками. Мне порой попадались приложения, которые на топовом железе прошлого
года выдавали ну просто сверх-тормозящие списочки. Впрочем, гигагерцы и ядра только
растут, а списочки все равно всегда тормозят.
Оптимизации сетевого обмена с сервером. Когда сервер задыхается от миллионов запросов,
то тут надо бы подумать, как сделать работу сервера попроще. К примеру, отказаться
от XML/JSON и других человекочитаемых протоколов, как бы ввести несколько серверов,
как бы снизить число запросов так, чтобы и функциональность не пострадала, и при этом
сервер без лишней надобности не трогать. Надо сказать, что это в общем-то не работа
Андроид-девелопера, но порой больше этим некому заниматься. Вопрос мог означать, умеете
ли вы работать с байтиками или ума хватает только на парсинг XML и голые запросы по http.
Иногда надо работать с большими объемами данных. К примеру, отображать карту с миллионами
объектов на ней одновременно. Да, это возможно, но если все приложение написать на
сишечке, а не использовать гугломапсы, как это делают все.
Есть ряд приложений, где отзывчивость критически важна и которые потребляют максимум
ресурсов. К примеру, Angry Birds делает внутри себя какую-то магию, что мой планшет
становится горячим примерно за 10 минут игры. Я не знаю как они этого добились, но
я верю, что это пример высоконагруженного приложения
Майнинг биткоинов, подсчет прогноза погоды, рисование чего-то поверх фотографий на
основе нейросетей. Возможно, в скрытом режиме. Наверное злые птицы чем-то таким в фоне
и занимаются.


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

А вообще, порог входа в профессию "погромизд на андроид" настолько низок, что достаточно
понимать как правильно копипастить код со стековерфлоу и клеить свои приложения из
копипасты. АПИ меняется постоянно, равно как и практики, равно как и требования. Я
совершенно не понимаю, зачем проводят такие собеседования.

Таблица с большим количеством строк

#highload #mysql

Интересует такой момент. 
Как работают таблицы с более > 10 000 000 000 строк?
Допустим, у меня есть мощный сервер + MySQL. Ну PHP там и прочее..

Как разбиваются таблицы? 
Как
   добавляются новые поля в разбитые
   таблицы? 
Как производится быстрая
   выборка из этих таблиц?


Допустим, у меня есть модуль пользователей - две таблицы: users и users_fields.
В таблице users_fields хранится информация пользователя (о себе, статус, номер телефона,
ссылки на страницу в соц. сетях и прочее). То есть, вся не системная информация.
Эта таблица сделана для того, чтобы можно было легко добавлять новые поля.
Каждая строка в таблице это информация какого либо поля пользователя.
uid | field | value

1   | status | тест
1   |   vk   | id1
2   | status | 
2   |   vk   | id2

Допустим, у меня есть 100 полей. При регистрации автоматически в таблице полей создаются
пустые поля.
Проблема в том, что если у меня зарегистрируются 100 000 000 пользователей, то количество
строк в таблице с информацией полей будет 1 000 000 000. 
Как быть в такой ситуации?    

Ответы

Ответ 1

Вам нужен шардинг - сегментация БД по некоторым признакам. Самое сложное здесь, определиться
с тем, как именно делить данные, т.к. методика сильно зависит от того, насколько данные
зависимы друг от друга.
В качестве простого и показательного примера можно разбить всех пользователей по
диапазонам ников. Для простоты будем учитывать только первую букву ника и считать,
что все ники записаны в нижнем регистре с использованием только лишь латиницы. 
Далее прикидываем каково распределение пользователей по первым буквам ников. В простейшем
случае на каждую букву выделяем свой сервер. Это конечно же расточительно. Поэтому
группируем пользователей по первым буквам таким образом, чтобы в каждом диапозоне оказалось
примерно одинаковое кол-во пользователей (т.е. чтобы распределение было примерно равномерным).
Теперь при чтении/записи мы всегда знаем, на какой сервер нам нужно пойти с запросом,
при условии, что у нас есть первая буква ника.
Понятно, что такая схема разделения данных не бесплатна. Распределение данных по
шардам может измениться. В таком случае нужно перераспределять данные.

Как происходит работа распределенного приложения?

Допустим есть большой и сложный проект, который будет в то же время высоконагруженным. Ненужно быть папой Карло, чтоб понять что 1 сервер его не потянет. Вопрос собственно вот в чём: как быть в такой ситуации? Попробую сам частично ответить на свой же вопрос и попрошу вас либо всё перечеркнуть, либо поправить. Приложение буду называть системой. Понятно как систему разбить на 2 части. На одной машине ставим сервер БД (в данном конкретном случае пусть это будет бесплатный MySQL Server). На другой - web-сервер (Пусть для наглядности Apache с подключенным модулем php), на котором будет исполняться сам код. Но что делать если сервер должен будет принимать по 10000 запросов каждую секунду. Понятно, что код надо оптимизировать. В БД по-хорошему работать с хранимыми процедурами, разумеется должно быть кэширование и т.д. Как быть, что делать, куда копать если нужно сделать так чтоб один исходный код выполнялся на нескольких машинах? И как быть, если сервер БД не справляется и нужно сделать так, чтобы один источник данных обрабатывало несколько серверов БД? Понимаю, что в ответ можно книгу написать и не одну, но буду безмерно благодарен хотя более-менее развернутому ответу.

Ответ

Читаем про memcache (и про его кластеризацию), GFS, кластеризация MYSQL. Так же, читаем про организацию livejournal - http://www.livejournal.com/doc/server/ Так же, можно обратить внимание на CDN технологию. Почитайте про eAccelerator и xCache (для кэша запиленного в байт-код PHP)..... Обязательно прочтите принцип работы nginx и apache (apache - backend; nginx - frontend ). Ну и , наверное, самое основное - откажитесь от прямой верстки HTML кода.

MySQL vs PostgreSQL vs SQLite для высоконагруженных сайта на PHP?

Здравствуйте! Подскажите, пожалуйста, какую БД выбрать(MySQL vs PostgreSQL vs SQLite) для высокоангруженного сайта на PHP в котором будет примерно 300 000 статей, и 50 000-60 000 заходов на сайт в день? Спасибо!

Ответ

Ну для больших проектов SQLite точно не стоит выбирать. А что касается MySQL и PostgreSQL, то это скорее зависит от собственных предпочтений и кривизны рук)) Несколько интересных ссылок: PostgreSQL vs MySQL: есть тесты на больших таблицах? PostgreSQL vs MySQL vs ... MySQL vs PostgreSQL

Как эффективнее всего распарсить огромный файл логов на слабой машине?

Есть сервер с 1gb RAM. Есть лог файл nginx (любой другой веб-сервер) на 70gb. Как максимально быстро собрать статистику по user agent пользователей сайта, учитывая описанные ограничения по ресурсам.

Ответ

можно воспользоваться StringTokenizer в языке Java, который позволяет считывать файл построчно и не тратить память на хранение всех строк файла.
StringTokenizer tok = new StringTokenizer("/path/to/file"); while (tok.hasMoreTokens()) { String line = tok.nextToken(); // работаешь со строкой. }
Также можно указывать разделитель в конструкторе, по умолчанию стоит \t

\f

Таблица с большим количеством строк

Интересует такой момент. Как работают таблицы с более > 10 000 000 000 строк? Допустим, у меня есть мощный сервер + MySQL. Ну PHP там и прочее.. Как разбиваются таблицы? Как добавляются новые поля в разбитые таблицы? Как производится быстрая выборка из этих таблиц? Допустим, у меня есть модуль пользователей - две таблицы: users и users_fields В таблице users_fields хранится информация пользователя (о себе, статус, номер телефона, ссылки на страницу в соц. сетях и прочее). То есть, вся не системная информация. Эта таблица сделана для того, чтобы можно было легко добавлять новые поля. Каждая строка в таблице это информация какого либо поля пользователя. uid | field | value
1 | status | тест 1 | vk | id1 2 | status | 2 | vk | id2 Допустим, у меня есть 100 полей. При регистрации автоматически в таблице полей создаются пустые поля. Проблема в том, что если у меня зарегистрируются 100 000 000 пользователей, то количество строк в таблице с информацией полей будет 1 000 000 000. Как быть в такой ситуации?

Ответ

Вам нужен шардинг - сегментация БД по некоторым признакам. Самое сложное здесь, определиться с тем, как именно делить данные, т.к. методика сильно зависит от того, насколько данные зависимы друг от друга. В качестве простого и показательного примера можно разбить всех пользователей по диапазонам ников. Для простоты будем учитывать только первую букву ника и считать, что все ники записаны в нижнем регистре с использованием только лишь латиницы. Далее прикидываем каково распределение пользователей по первым буквам ников. В простейшем случае на каждую букву выделяем свой сервер. Это конечно же расточительно. Поэтому группируем пользователей по первым буквам таким образом, чтобы в каждом диапозоне оказалось примерно одинаковое кол-во пользователей (т.е. чтобы распределение было примерно равномерным). Теперь при чтении/записи мы всегда знаем, на какой сервер нам нужно пойти с запросом, при условии, что у нас есть первая буква ника. Понятно, что такая схема разделения данных не бесплатна. Распределение данных по шардам может измениться. В таком случае нужно перераспределять данные.