使用磚作為應用程序的數據庫?

[646901年]

是磚適合用作應用程序的數據庫?我一直要求建立一個相當大的CRM應用程序類型,磚將使用的數據從這個分析。我在想如果我建立了應用程序數據庫內部磚我可以簡化後的流程得到數據的sql類型的數據庫。

磚適合作為應用程序數據庫或應該隻用於Datalake和倉儲。

[karthik_p]

@Matt用戶數據磚主要用於大數據處理,或如果你需要清洗/轉換,最後想在BI使用它們,可以用,如果隻是正常的應用程序數據庫沒有任何清洗那是你的電話。我們將等待社區成員的反應,看看任何一個使用磚作為正常的應用程序數據庫

[匿名]

嗨@Matt用戶

希望一切進行得很順利。

隻是想檢查如果你能解決你的問題。如果是的,你會很高興的答案標記為最好,其他成員可以找到解決方案更快嗎?如果不是,請告訴我們,我們可以幫助你。

幹杯!

[1782390347]

所以我們公司采用磚2021年早些時候,通過niavity磚是真理的“源”的我們所有的數據和應用程序。我們可以構建應用程序,報告和分析都在一個地方,似乎一切都合並到一個地方的聖杯。

我們的組織已經搬離了這個模型和現在的所有應用程序都與磚但datastroage發揮他們的優勢。事後看來,這並不是一個聰明的想法使磚的一個數據庫的規則。

磚越我們固定的應用程序的數據模型的事情變得更加脆弱,應用coulpling減慢團隊,有一個稀釋的數據很重要在我們datalake /倉庫。

Handilng對話/特定於應用程序的狀態越來越痛苦,以及擴展應用。

我們總是損害應用程序使事情工作pyspark /磚方式。甚至管理應用程序數據的內部磚剛才添加的額外的complextity和clunkiness。

模式,ETL和處理成為交織在一起的團隊感覺他們對抗一個失去戰鬥的日常變化將打破其他東西。

是的,accessiblity數據是“簡單的”,但在大多數其他事物的成本。

IMHO(和磚的書麵文檔)磚是lakehouse /倉庫,因此應該保持這種方式。您可以添加應用程序數據磚和它似乎快和容易每天直到你comprosing和救火。

[pvignesh92]

嗨@Matt用戶。如果我理解你的問題,你想為你考慮使用三角洲湖CRM數據庫。

1. 延遲- >讀取和寫入延遲多少你期望在三角洲湖嗎?數據庫的數據組織方式是有很大不同的三角洲湖作為數據將在雲坐在不同的塊對象存儲。
2. 並發性- >你期望多少讀寫事務發生在三角洲湖嗎?目前三角洲湖支持快照隔離讀我相信。你想要讀和寫是孤立?
3. 主鍵索引- >沒有索引或者概念在三角洲湖。你期待一些事情像這樣來加速你的搜索?

等領域有很多,你需要探索得出結論前你需要選擇。希望這個有幫助。