Нужно только где-то очень толстую троичную память найти

Вот совсем толстую

Все будет работать одинаково говняно :) компромис

Вот например еще один подход к снаряду: https://medium.com/@PingCAP/delivering-real-time-analytics-and-true-htap-by-combining-columnstore-and-rowstore-1e006d3c3ef5

Всем привет, а не подскаете пытаюь поднять Thrift Server, и в конфигах хадупа в hive-conf.xml прописываю путь hive.metastore.warehouse.dir -> /home/sparker/metastore_db2 но при запуске через start-thriftserver.sh он везде пишет что

2020-01-20 08:57:37,228 INFO internal.SharedState: spark.sql.warehouse.dir is not set, but hive.metastore.warehouse.dir is set. Setting spark.sql.warehouse.dir to the value of hive.metastore.warehouse.dir ('/home/sparker/metastore_db2').
2020-01-20 08:57:37,228 INFO internal.SharedState: Warehouse path is '/home/sparker/metastore_db2'.
2020-01-20 08:57:38,116 INFO client.HiveClientImpl: Warehouse location for Hive client (version 2.3.6) is /home/sparker/metastore_db2
2020-01-20 08:57:52,417 INFO client.HiveClientImpl: Warehouse location for Hive client (version 2.3.6) is /home/sparker/metastore_db2

но при этом создает /home/sparker/metastore_db и пишет в нее, может кто знает за что?

2020-01-20 08:57:37,228 INFO internal.SharedState: spark.sql.warehouse.dir is not set, but hive.metastore.warehouse.dir is set. Setting spark.sql.warehouse.dir to the value of hive.metastore.warehouse.dir ('/home/sparker/metastore_db2').
2020-01-20 08:57:37,228 INFO internal.SharedState: Warehouse path is '/home/sparker/metastore_db2'.
2020-01-20 08:57:38,116 INFO client.HiveClientImpl: Warehouse location for Hive client (version 2.3.6) is /home/sparker/metastore_db2
2020-01-20 08:57:52,417 INFO client.HiveClientImpl: Warehouse location for Hive client (version 2.3.6) is /home/sparker/metastore_db2

-Dderby.system.home пробывал

И?

Взяли kv для oltp, сверху натянули спарк для того чтобы как-то делать агрегации

Агрегаты все равно медленно

Добавили екстеншен по репликации данных в колумнар формат расположенный рядом в соседнем кластере

ООО, по колумнар формату у нас производительность даже чуть быстрее чем у паркета!!!

То есть имеем 2 системы под капотом с дублированием данных, такие же системы половина чата строит на рабочих местах.... Голден гейт с переливной данных или mysql с binlog когда на разных репликах разные движки уже давно норма

Так задача в том, чтобы не надо было нанимать DE, чтобы строить инфру, а можно было бы просто использовать готовое решение ;-)

свежо предание, да верится с трудом

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

да, это я тоже обратил внимание, там про задержки репликации и атомарность в аналитическом ни слова

а, не тут, в другом чате я это обсуждал

в другом месте уже пару раз на tidb нарывался

Ну посмотрим. Может быть это ошибочная ветка эволюции, но факт в том что многие сейчас этим занимаются и в течении пяти лет, мы увидим такие системы, в облаке, at least.

ну с учетом что первый раз «скрытую федерацию» я видел в IBM DB2 Data Joiner в 2001-ом году - то очень скоро должен быть успех, any day now

10 лет назад я слышал про nuodb, наша компания даже им делала переливатор данных по миграции данных из обычных реляционок в их систему

тогда newsql был ещё тем хайпом
ждёмс…..

Ну а сейчас newsql это реальность.

можно примеры? =) а то у меня всё nosql где много данных или sql где нужны честные транзакции

Приводил уже.
Aurora, Spanner, Voltdb, Yandex db

это все примеры снятия дополнительных миллисекунд за счет технических трюков, все на ОЛТП, и это хорошие и нужные направления, но они не стремятся решить ХТАП проблемы