landergate

У контактов может быть несколько сделок, у сделок несколько контактов и т.д.

Сделайте однозначную иерархию.

Чтобы ускорить выборку, нужен индекс (можно "самодельный"). Для этого данные должны быть достаточно денормализованы.

1. Вы mysqltuner запустили не дав проработать даже 24 часа бд. Лучше попозже его ещё раз глянуть.
2. Выполнить все его рекомендации.
3. Вес таблицы не особо большой. А сколько там строк?
4. Что именно беспокоит то? Медленные запросы отследите ведите slow log и error log mysql смотрите что туда будет падать. Оптимизируйте тяжелые запросы.
5. Можете поставить утилитку mytop и следить в режиме реального времени на плохие запросы. потом их оптимизировать.
6. Использовать индексы. Если используются пересмотреть правильно ли проиндексирована таблица.
7. По медленным запросам можно использовать explain.
8. Если таблица innodb то можно ускорить её работу отключением сброса данных на диск innodb_flush_log_at_trx_commit = 2. (но тут есть свои подводные камни загуглите).
9. Можно настроить перемещение временных файлов mysql не на диск а в tmpfs (дирректива tmpdir ) это ускорит немного совсем работу всего mysql сервера.
10. query cache - настройте. кто бы что не говорил он помогает. (но так же надо тестировать может в вашем случае будет лучше а может и нет)
11. key buffer size настройте в соответствии с ОЗУ
12. Если совсем много rps (да и в любом случае) крутаните ядро расширьте лимиты /etc/sysctl.conf /etc/security/limits.conf
13. Ну и конечно что итак понятно использовать хороший сервер многоядерный с ssd в raid-e.
14. Ну и конечно убедитесь что правильные типы полей используйте в таблице возможно можно ещё оптимизировать саму архитектуру таблицы. Тем самым при использовании правильных типов можно и вес снизить таблицы.
15. Возможно в таблице куче не нужных записей которые уже никогда не пригодятся и их надо чистить по крону раз в сутки допустим?
16. Ну и конечно для ускорения работы всего mysql сервера не писать bin log и general log.
17. Если табличка myisam то может сильно дефрагментируется? иногда можно и optimize table выполнять тогда.
18. Если совсем всё мощно и дохрена запросов к ней (хайлоад проект) то уже смотреть можно в сторону кластера/репликации.

Я делаю так(linux):
Установлен vnstat. cron каждые пять минут пинает

*/5 * * * * /usr/bin/vnstat -i eth0 --json > /home/vns.json

Или xml, если неудобно json

*/5 * * * * /usr/bin/vnstat -i eth0 --xml h > /home/vns.xml

Затем беру либу json

import time, json
from pprint import pprint
localtime = time.localtime(time.time())
z = localtime[3]

with open('/home/vns.json') as json_data: 
    dat_j = json.load(json_data) # 
    json_data.close()

out = round(dat_j['interfaces'][0]['traffic']['hours'][0]['rx']/1024, 2)

И делаю c переменной dat_j что хочу.

Так ведь есть уже. HHVM называется, там даже язык есть в виде улучшенного PHP - Hack называется.

Сейчас разработчики пишут портал

Вот у разработчиков и спрашивайте, какую СУБД они лучше знают. И админов своих спросите, какую СУБД те лучше знают. DBA у вас явно нет, иначе вопрос бы так не стоял.

Сам headhunter использует postgresql. Но там и своя команда админов классная, и вдобавок опытная команда DBA моих нынешних коллег, специализирующихся именно на postgresql.

Я достаточно хорошо знаю обе СУБД с точки зрения разработчика, но не умею админить mysql, так что моё мнение будет предвзятым.
Если делаете коммерческий проект - то используйте ту СУБД, которую лучше знает ваша команда. Если разработчики попрятались за своими ORM'ами и носу не заглядывают в базу - то без разницы, в таких условиях любая СУБД будет работать одинаково плохо. Если же хоть кто-то в команде понимает, что надо делать с базой - доверьте выбор ему и поинтересуйтесь о причинах выбора.

https://www.coinbase.com/merchants

Можно поискать дампы сообщений из Twitter, некоторым университетам по-моему полную историю твитов давали на изучение (хотя это и не совсем переписка). А так спарсить несколько веток форума мне видится самым реалистичным вариантом.

В контору. Попробуй в "Тензор" - берут твоего возраста без проблем, если голова на месте.

идите в оба направления

Уже был подобный вопрос. Не нужно спешить начать работать раньше времени, еще успеете хлебнуть рутины. Идите учиться. А работать идти можно по исполнении 18 лет, не раньше.

А я бы посоветовал - сейчас ни туда и ни сюда. Если есть шея, на которой можно еще посидеть до 18.

Почему.

- Фриланс. Понятное дело, никто не спрашивает документы, никто не требует образования, берешь и делаешь. Ты сам себе и джун и сеньор и менеджер проекта. Постепенно возникает привычка самому нести полную ответственность - да, проекты крошечные, но и крошечный проект нужно сделать от начала до кончала. Особого стимула развиваться нет - оседлал какую-то технологию и клепаешь на ней, Год, два, три...пока она популярна. Только люди с невероятно сильным характером способны допустим отложить выгодный, но скучный проект ради не особо выгодного, но интересного. В итоге - делаем сайт, второй, третий...двадцать пятый - деньги есть, развития нет.
- Офис. Если не контора "Три стола два стула LLC", то проблемы с трудоустройством начнутся еще до самого трудоустройства. Могут отказать банально из-за нежелания связываться с ТК в части работы несовершеннолетних - вот тут подробно написано. Опять же всяческая "ерунда" типа медкомиссии при приеме на работу, инструктажей по охране труда и прочее. Зато команда людей с разным уровнем, которая реально будет подтягивать, особенно если есть толк. Правда, такую контору, которую бы не испугали проблемы еще найти надо. Опять же денег будет сильно меньше чем во фрилансе

Можно ли пару лет пофрилансить, а потом - на галеры?

Можно. Но с галер в таких случаях, как правило быстро просят. Почему? На галере есть такой человек - гребной мастер. Он ударами в барабан задает ритм команде. Фрилансер сам себе мастер - как хочет так и гребет. В офисе грести нужно в темпе, который задает мастер - а за пару лет выработается устойчивая привычка грести самому - и постоянно будут конфликты, что мастер криворукий, весло не такое, сляйд с ржавыми колесами...

Поэтому я бы советовал работать только в том случае, если нет шеи, которую можно оседлать, если же она есть - не спешите во взрослую жизнь - еще накушаетесь :)

Ну, могу предложить linkedin, indeed, monster.com/job
Возьмут ли с вашими знаниями на удалёнку? Не знаю - пробуйте. Даже если все говорят, что нет, сначала нужно убедиться самому или доказать, что это не так.

можешь триггером на каждый селект

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

Во первых, вы неправильно используете анонимные функции, например
const startTimer = (){ ... }
и все остальные.
Анонимные функции можно использовать только в ситуациях, когда их вызывают "не по имени" для сохранения контекста. Например, аргументом forEach().
В данной ситуации лучшей синтаксической формы ничего не придумали:
function startTimer(){ ... }
Второй момент

for ( const key in _headers ) {
        if ( {}.hasOwnProperty.call( _headers, key ) ) {
            headers.append( key, _headers[ key ] );
        }
    }

и конкретно
if ( {}.hasOwnProperty.call( _headers, key ) )
Вы в цикле каждой итерацией создаете новый объект, это крайне не рациональное использование метода hasOwnProperty()
по мне
if (_headers != null && !!_headers[key] )
может выглядело бы не так красиво, за то потребляет памяти по-меньше.
Третий момент
.catch( console.error )
Вы можете немного сэкономить памяти использовав как раз по назначению анонимную функцию
.catch( e => console.error(e) )
В этом случае интерпритатор не будет искать ссылку на console.error при создании каждого промиса, и будет искать, соответственно, только в исключитальных ситуациях.
Четвертый момент
Поменьше пользуйтесь ключевым словом const, особенно, внутри методов и функций. Во-первых, так как они не выгружаются из памяти. Во вторых, const не дает никаких преимуществ в производительности, только лишь накладывает на интерпритатор обязанности следить чтобы ее случайно не перегрузили.