Teradata 推動響應式 Web 應用程序
有沒有人有使用 Teradata 驅動典型的響應式客戶端 Web 應用程序的經驗？你的評價是什麼？具體來說，它在單讀和單寫方面的表現如何？
Single-read：發送請求和接收響應之間的總時間到第一個字節，以讀取包含對 web 應用程序有意義的資訊的單個文件或行。例如，考慮一個
profiles有 100,000 條記錄的表，其中每一行都儲存了各種屬性。通過查詢主鍵將單個配置文件上傳到客戶端 Web 應用程序需要多長時間？做同樣的操作需要多少時間，查詢一個非索引欄位？單寫：插入新行或更新現有行需要多長時間。假設需要在單次寫入操作期間寫入快速執行單次讀取所需的所有索引。
如果您使用 Teradata 後端建構了客戶端 Web 應用程序，您面臨哪些挑戰？我認為 Teradata 主要是一種分析和數據倉庫工具，而不是一個可操作的數據庫，但我被要求研究 Teradata 作為可操作 Web 應用程序的後端。
我想知道是否有人嘗試過這個，以及它是否可以跟上更常用的 webapps 數據庫。我不是在尋找意見，而是在尋求測試人員對技術在這種不尋常案例中的工作方式的誠實評估，以及人們使用 Teradata 驅動響應式 Web 應用程序的體驗。
我知道這裡有很多變數，但我正在尋找 Teradata 被用作客戶端 Web 應用程序後端的真實範例，以及它在實踐中的表現。因此，與 DBS 時間相比，我對 TTFB 更感興趣，儘管對每筆交易需要多長時間的徹底細分將不勝感激。
我之前的問題Teradata REST API 性能指標專門針對 Teradata REST 性能。但是，我意識到在這個社區中幾乎沒有人使用 Teradata 的 REST 功能（問題多年來一直沒有得到解答）。
我的特定案例
Insac 要求我分享我的特定案例的一些細節，以幫助集中答案。需要注意的是，我正在尋找有關 Teradata 對 web 應用程序的一般性能的答案，以下是我的應用程序需要做的事情：
- 帶有 RESTful 介面的客戶端 webapp
- 估計約 5,000 名使用者
- 將由約 25 個 Terdata 視圖和少量物化表驅動
- Teradata 實例將與數據倉庫共享
- 一些視圖會跨多個底層視圖執行連接
- 這些視圖的基礎表是為分析而建構的
- 幾乎所有查詢都是只讀操作；當然所有密集的查詢。
- 典型的頁面刷新會在收到一些初始查詢的響應後向 Teradata 發送約 100 個查詢，以在客戶端動態生成 SQL。
- 至少，任何使用者操作都會發送大約 20 個查詢。
- Web 應用程序需要具有響應性和流暢性。要求在 2 秒內做出響應，亞秒級響應時間是首選。
一個非常高級的目的概述是訪問來自特定個人資料的類似社交網路的時間線提要歷史記錄中的數據。初始查詢將返回按時間排序的事件列表，這些事件與類別和日期等基本過濾器相匹配。然後，此結果集將驅動動態生成的 SQL 查詢以獲取第一個結果，並返回提要上每個事件的內容。
我正在為這個應用程序評估 Teradata，但一般想知道 Teradata 是否適合客戶端 Web 應用程序，以便我也可以支持對未來項目的數據庫技術進行比較分析。
編輯：我的項目範圍正在轉移以包含更多 web-2.0 功能，這意味著應用程序需要寫入多個視圖，並且寫入將是 webapp 使用的常見部分。刪除只讀約束後，Teradata 上的 web 應用會是什麼樣子？
正如我在回答這個問題時所說的那樣，Teradata 不會是我作為 Web 後端的首選：它確實適用於移動/處理大量數據，但應用程序的典型工作負載（頻繁的小查詢）不是最好的情況。
顯然還有其他的聲音（見這裡），但在一些關鍵點上有相當一致的意見：
Teradata 鎖定行為是 OLTP 風格應用程序的主要挑戰。
和：
盡可能多地使用記憶體：Teradata 連接是一種寶貴的資源，您最好不要將其用於不需要實時的資訊
在 Teradata 上實施這樣的解決方案顯然並非不可能，但它要求您的應用程序完全適應 Teradata 的特性（例如，您可能必須創建一個重要的應用程序數據模型，以爭取單 AMP 查詢）
您將面臨的挑戰的一個範例：
在應用程序中，我必須更新表中一組行上的標誌欄位，選擇條件不是 Teradata“主索引”。但是，條件中使用的列上有一個索引。
通常，我會使用一個簡單的“更新”：但是，在 Teradata 中，這會創建一個“表級鎖”。最後事實證明，選擇應用程序中的所有行並按主索引一一進行所有更新（批量）以使用“雜湊級”鎖是“更好的”。
=========================================================
**編輯：**在來自 OP 的附加資訊之後
首先是好消息：
主要是只讀的， 因為它是一個主要是“只讀”的應用程序，您可以設置一個高效的記憶體系統。您還可以“預記憶體”一些常見的內容，這樣第一次查詢的結果對使用者來說就不是很明顯了。
為什麼這在這種情況下很重要： Teradata 中的連接無法通過特定數量的設備創建。這是一個將在應用程序中的使用者、ETL 和普通 OLAP 使用者之間共享的池。此外，非單AMP的查詢不會有很好的延遲，它們會更受系統的即時負載影響
細粒度查詢
如果您能夠以這種方式進行大部分單 AMP 查詢，那可能是一件好事。
為什麼這在這種情況下很重要： 單 AMP 查詢（使用主鍵作為條件進行查詢/插入/刪除的查詢）具有較低的鎖定影響，並且可以在不支付 AMP 之間協調成本的情況下進行管理。另一方面，擁有這樣一個“健談”的協議將佔用更多的連接。
物化表
很高興您已經在考慮具體化一些數據。您甚至可能會發現，將相同的數據具體化在兩個或多個具有不同主索引的表中會很有用，以滿足您的使用者界面（例如，如果您對同一實體有不同的選擇標準）。但是，這將在 ETL 時間和磁碟空間方面產生成本。
現在，壞消息：
超過 1000 個使用者 由於應用程序不是“完全”只讀的，這個數量的使用者可能會在他們必須寫入的情況下產生訪問衝突。
為什麼這是一個問題： 忘記多版本控制：這裡讀者會阻止作者，反之亦然。您的選擇可能會阻止其他使用者的更新完成。如果您無法在每次更新時使用主索引，您將鎖定整個表，並且即使您使用主索引，您也不會擁有行級鎖定（您有一個“散列-級別”..通常可以正常工作，但是批量插入可能會出現一些問題）。讀者和作者之間的衝突有一個解決方法（LOCK ROW FOR ACCESS），但它為臟讀打開了大門，您應該仔細考慮是否可以在您的應用程序中接受這一點
Web 應用程序和 OLAP 在同一台機器上
獨立於底層技術，在同一平台上容納這兩種不同的工作負載始終是一個挑戰。
為什麼會出現問題： Teradata 有一些工作負載管理規則可以在這個領域提供幫助，但是它們需要 DBA 仔細調整，但是，異常負載（例如月末批處理）可能會對使用者體驗產生影響應用
每小時 ETL
每小時的 ETL 將成為應用程序的壓力點，因為您將載入正在查詢的相同表。由於無法鎖定讀取器，因此您可能會求助於“臟讀”，但您必須找到一些策略來管理應用程序可能具有暫時不一致的數據這一事實。
為什麼這是個問題： 已經說過：表鎖、臟讀和兩種不同工作負載的存在
查詢數
我知道我說過“更精細的查詢”可能是一件好事，但這裡我們說的是每個使用者對一個頁面進行 100 個查詢，並且每個使用者操作至少有 20 個查詢。現在，如果您連續執行它們，您會增加延遲（並且您正在尋找亞秒級響應時間）；但是，如果您將它們並行化，您將佔用相當於一個解析引擎的最大會話數（我不考慮在這裡記憶體）
免責聲明：過去兩年我一直在從事更傳統的 Teradata 項目，但是當計算 OLTP 和原始延遲時，我不記得數字比你提到的 150 毫秒要少得多。可能是 130 毫秒。但那是在優化和配置系統以適應我們的工作負載之後，並且只是在更簡單的查詢/宏上。
但是，如果您已經有一個實例，並且您想驗證 Teradata 在這種情況下的性能，我建議您向 Teradata 銷售支持尋求關於您的環境的“概念證明”。我認為他們會很樂意接受（您的負載越多，您需要額外節點的可能性就越大）。
我想知道關於您的應用程序的這麼多事情的原因是，在某些條件下（主要是讀取數據、很少有活動使用者、明確定義的批處理和線上視窗），很容易在 Teradata 上創建應用程序（就像在其他所有系統上一樣） . 當其中一些限制被解除時，鎖定架構和針對單 AMP 查詢的必要性使得實現令人滿意的性能變得非常困難（並非不可能，但非常困難）。