Кстати я согласен с "Процент людей, успешно начавших свое дело, далек от 98%", с таким же успехом можно сказать: "Процент людей, успешно начавших свое дело, далек от 170%"
> переехать в другую страну и удачно обосноваться
Успешно обосноваться и без переезда не просто, "успешно начавших свое дело" - тут тоже все под вопросом (успешно начал, но быстро кончил?)
вообщем это уже офтопик, речь про тех кто обосновался, а не про тех кто удачно это сделал.
Тимур: из экономических передач по тв, радио и собственных наблюдений,
например можете посчитать кол-во ютуб каналов/людей сколько уехало, сколько вернулось.
Тимур: Это статистика со слов (озвученные данные, вы же данные спрашиваете), какая разница, на бумажке она или по телевизору, тут больше вопрос доверия, мне этого достаточно для подтверждения.
Если вам нужны конкретные цифры - гугл в помощь.
Виталий: никто тут и не хаит sql (и рсубд), sql даже в некоторых nosql используется.
А вот большие объёмы, это как раз не про рсубд зачастую.
> скорость упала на порядок на некоторых операциях
я часто видел бенчмарки где обвиняли в тормозах очередную БД, хотя дело в кривых тестах. Может нет нужного индекса или не хватает памяти или ещё что (внешние силы), нужно искать причину.
Некие джойны есть и в монге, а например в OrientDB есть транзакции, джойны, ссылки и т.п.
В движке монги (wiredTiger) есть транзакции, есть и в плане, возможно и в самой монге появятся.
В итоге рсубд лишь отличается методом хранения который не является идеалом.
Поэтому все БД можно свалить в одну кучу и выбирать по фичам.
Виталий: не знаю про какую статью речь, но это не повод покупать трактор для поездок по городу с мыслью что когда-нибудь надо будет пахать поле.
На старте надо максимально просчитать необходимое, а когда понадобится то чего нет, уже думать исходя из имеющегося. Поэтому часто в больших проектах можно увидеть зоопарк разных (конкурирующих) технологий вместе.
VoidVolker: вот интересны причины возврата, скорее всего не получилось, никому не нужен. По статистике, возвращаются 1 на 50.
А вообще, пожить как турист и жить там совсем разные вещи.
latteo: все данные резались на чанки и запаковывались, каждый чанк имел свои индексы.
Резать чанки надо так, что-бы максимально эффективно потом можно было доставать, т.е. под запросы.
Очень часто одним из индексом бывает время, т.к. данные обычно запрашивают за какой-то период, а не за всю историю. Т.е. идет нарезка на часы/дни/месяца и т.п. Далее день нарезается на второй (третий) индекс. Чанки паковались xz/bzip без заголовков, и разъезжались по шардингу. Использовалось максимальное сжатие т.к. чтение редкое, а хранимые данные занимают место постоянно.
Итого запросить и распаковать 500 чанков горадзо быстрее чем извлечь 500М строк из БД. + большая экономия на памяти и индексах.
jsbin.com/gicewezuki/1/edit?html,output