本文分享自華爲雲社區《究竟什麼樣的數據庫，才能承接RTA廣告這個技術活！》，作者： GaussDB 數據庫。
廣告投放費錢效果差，該如何解？
廣告投放是企業宣傳營銷不可或缺的一部分。尤其是在新媒體發展白熱化的當下，不僅廣告渠道多樣化，投放模式也更細節化和個性化。
隨着客戶廣告投放產出比意識的加強，以短視頻平臺、微博等渠道爲例，在投放目標選擇上，廣告主通常需要通過配置年齡、性別、學歷等偏好規則，才能將廣告投放給滿足標籤的受衆，投放中這一靈活性不足的限制，常常會讓廣告主難以抉擇，導致投放效果不佳。
普通廣告投放僅支持有限的人羣標籤，投放效果一般
廣告主企業往往每年需花費數億甚至數十億廣告費，卻依然難以準確觸達目標用戶，造成大量資金浪費。那該如何解決“讓廣告主對每一條廣告請求，有投遞或者拒絕的自主權”這一問題呢？
廣告RTA應運而生！
廣告RTA業務流程大揭祕
RTA（Realtime API），是一種用於滿足廣告主實時、個性化的投放需求的技術手段。其廣告投放流程如下舉例：
- 小王在刷短視頻或文章資訊過程中，平臺在短時間內做出反應，我要給小王曝光廣告；
- 緊接着，媒體側會詢問多個廣告主是否要投遞廣告；
- 多個廣告主收到消息後，會迅速作出反應，將這個用戶與設定的投放標準一一對比。如果符合要求，就會答覆要參與競價投放；如果不符合要求，答覆本次不投放；
- 媒體側收到每個廣告主的反饋後，如果有投放意願的廣告主，通過競價排序等環節，向用戶（小王）曝光一則廣告；反之，小王也就沒看到其廣告；
- 對於超時未答覆的廣告主，媒體側採取自帶默認策略，就會導致投放效果不佳。
廣告RTA業務流程
廣告RTA要想效果好，數據庫挑戰少不了
廣告主的RTA系統，是從核心的畫像數據庫讀取數據並進行投放決策的，數據越“新鮮”，投放效果越好。因此，大數據平臺生成的最新數據，需要及時寫入畫像數據庫。綜合來看，廣告RTA對核心畫像數據庫有以下訴求：
1.能承載高併發訪問
廣告主往往會在多個媒體側投放廣告，因此，RTA系統要承接大量的實時競價請求。以電商、金融客戶的RTA系統爲例，經驗上，日常數據庫QPS通常在幾十萬到數百萬之間。
2.保持穩定的低時延
媒體側對時效性要求很嚴苛，通常需要廣告主在40-100ms內返回決策結果，排除掉複雜的業務決策計算，留給數據庫的時間非常短，必須在個位數毫秒內執行完請求，對數據庫挑戰非常大。
一旦響應超時，平臺會認爲棄投或者默認投遞，投放效果差，損害了廣告主商業利益。
3.海量數據快速導入，確保決策精準性
離線業務會定期生成全量畫像數據，如果能把這些成百GB甚至數TB的價值數據第一時間導入畫像庫，就會極大提升RTA投放效果。但並非所有數據庫都能在短時間內導入成百GB甚至數TB級的離線數據。因此，有時業務不得不捨棄數據實時性，將數據分組，連續數晚，利用業務低峯才能將數據低效導入。
除此之外，降本也是廣告主對數據庫的核心訴求。部分客戶會選擇將畫像數據壓縮後存儲，讀取後再解壓，以降低成本，這樣給業務帶來比較大的資源和開發負擔。
放眼數據庫，誰能滿足廣告RTA高要求？
隨着數字化進程的加深，應用端數據量呈幾何式增長，業務場景和用戶需求也更加多元化。數據庫作爲數據存儲的底座，勢必會面臨巨大的挑戰。廣告RTA以在“高併發、低時延”有嚴苛著稱，究竟哪個數據庫才能承受的住來自廣告RTA的挑戰呢？
以常用的幾個數據庫爲例，
- MySQL：難以承載數十萬至百萬QPS併發；
- Hbase/MongoDB：容量大，無法滿足穩定低時延訴求，很容易導致投放超時；
- Redis：基於併發和時延性能考慮，業界比較多的RTA選擇使用開源自建Redis。但是隨着業務增長，開源自建Redis會面臨存儲成本和離線數據導入慢這兩大瓶頸問題。
華爲雲GeminiDB Redis接口在廣告RTA場景上，不僅解決了開源自建Redis存儲成本和離線數據導入慢的瓶頸問題，還具備"穩定低時延、節約存儲成本、FastLoad極速導入" 三大核心能力，擁有豐富的線上廣告、推薦類業務的實踐案例。
總結
RTA廣告競價業務近年來發展潛力巨大，一方面要滿足媒體側的性能指標要求，另一方面又要承擔企業降本重任。在這類典型大數據業務中，無論從性能、穩定性，還是大容量、低成本，華爲雲數據庫GeminiDB Redis接口能夠兼顧性能與存儲降本需求，是其最佳存儲選型，歡迎做廣告推薦類業務的小夥伴使用體驗。