influxdb не подходит по тем же причинам (кастомные индексы насколько я знаю должны появится в 0.9).
pg справился хорошо — одна большая таблица и несколько индексов.
Да, но rrd/carbon не подходил — выборки не только по time индексу, в К держал двойную-тройную копию данных под разные запросы. influxdb на тот момент был еще слишком молод.
Дело в том, что задача — накопление данных скажем по датчикам, чтото типа timeseries (что как раз хорошо ложится в идею К). Можно решить реляционными БД? Конечно, но хотелось использовать чтото заточенное под накопление данных. После сравнительных тестов мускль, К (4 ноды в кластере) и простой постгрес. Победил постгрес по всем показателям.
Подтверждаю, со многим столкнулся. И в моем случае postgresql показал лучшие результаты по скорости выборки. И вместо mysql+C* просто перешел на postgres.
Если Вы до сих пор не уловили в чем прикол — у Вас ни малейшего понимания JS
node jstp.js
parse: 1ms
{ a: 1, age: [Function] }
call age(): 2703ms
Картинка из Вашего профиля как бы намекает
ДА Вы еще и JS не знаете!!!!111
в данном случае timeout Вам не поможет — зависнет функция в основном потоке, а не в
Я был не прав, у Вас не большие проблемы в образовании, а очень большие.
Императивные инструкции в протоколе, жестко завязанные на реализацию какого либо языка ??
Почерк архитектора! че…
А Вы точно архитектор? Преподаватель?
И да, ждем отдельную, подробную статью
pg справился хорошо — одна большая таблица и несколько индексов.