Комментарии 11
Сначала я вычеркнул базы данных, которые являются коммерческими — мне просто не хотелось рассматривать такие решения.
ведь никто не может гарантировать, что владелец VK или mail (за чей счет он щас делевелопиться? ) вдруг не решит, что неплохо бы сделать бесплатный тарантул платным.... Ну а иностранные компании принципиально будут избегать продуктов под такими брендами. Стоит ли осваивать продукт с такими ограничениями?
Ну тогда и PostgreSQL не надо рассматривать – а вдруг?
Так-то Tarantool выпущен под BSD-лицензией, и всё, что надо некорпоративному пользователю, там есть. Мало того, vk – не единственная компания, предлагающая поддержку Тарантула.
Странные вопросы! А стоит ли осваивать вообще что-то OpenSource, если с ним может произойти то, что произошло с Java (смена лицензии) или Elastic (так же смена лицензии)? А с Postgres такое не может произойти, может и PG нет смысла изучать?
Tarantool Enterprise уже как много лет существует и продается.
Уже выпушенные в opensource версии никуда не денутся, новые могут оказаться коммерческими, да, но вы всегда сможете сделать свой форк :)
Критерий шустрости не всегда основной.
В моей практике надежность наиболее важна. Также, важна поддержка языками, ORM.
А шустрость допиливаем кешированием: на сервере (ex. Redis), на клиенте (ex. IndexedDB).
Ни о какой универсальности тарантула конечно же не может быть и речи. Вы либо не понимаете этого, либо понимаете, но пишите так намерено. Хочется надеяться на второе, но количество неверных высказываний и технически неправильных утверждений скорее говорит о первом варианте.
Добавьте, пожалуйста, конкретики. Почему об «универсальности тарантула не может быть и речи»? Я не понимаю, и хотелось бы почитать развёрнуто, что не так в статье? С сабжем дела не имел вообще.
Универсальная БД - это которая может закрыть большинство задач работы с данными в том числе те, которые автор сразу вычеркивает.
Универсальная должна:
Уметь эффективно решать аналитические задачи
Уметь решать транзакционные задачи OLTP
Решать она их должна одновременно и желательно иметь на борту resource management чтобы, например, обеспечить SLA вида 70 млн запросов в час и перманентные long running transactions типовой аналитической нагрузки пару тройку тысяч в течение дня.
Удел таратула - объемный и масштабируемый кэш данных с обвязкой интеграционных сервисов над этим кэшом и транзакционным доступом.
Вопрос объема тут чисто расчетный. Вопреки утверждению автора, любой объем, нагрузку дисковой системы аппаратное обеспечение и отказоустойчивость достаточно легко рассчитать и обеспечить.
В большинстве случаев "под транзакциоонный кэш" после расчета выясняется, что, например MS SQL Server на дохленьком 4 vCPU и 16Gb в in-memory держит до 20 тыс операций в секунду. Если в ближайшие 5 лет я не собираюсь расти до объемов сотен гигабайт, то зачем мне паук? Потому что "стильно, можно молодежно"?
Получилось что автор сперва выбирает себе удобных соперников, а потом совсем не убедительно доказывает превосходство своего кандидата при этом не приводя никаких проверяемых доказательств и фактов и внятной аргументации. предлагается просто поверить в "данных мало" или "данных много"
Тут можно очень долго цитировать неточности, ляпы, неверную информацию и тд, но я приведу пожалуй один пример "OLTP — это когда мы делаем маленькие точечные запросы. В качестве примера можно привести объектное хранилище (S3), у которого точечная нагрузка, которая строго ограничена конкретными объектами. " no commets
Неплохо было-бы добавить независимый анализ, типа https://jepsen.io/analyses
Надеялся прочесть о реальных кейсах в бою, примерами реализации для кэша и может чего ещё, а прочёл кучу воды...
Если кто хочет напихать минусов, то хотя бы в в ответ напишите, где тут хоть какие то описания для чего его использовать то? Какие то рассуждения об одном и том же на всю статью.
Откуда такое название? Почему?
Tarantool: Билли Миллиган в мире СУБД