StarRocks數(shù)據(jù)庫(kù)詳解(什么是StarRocks)
StarRocks介紹
StarRocks，作為新一代極速全場(chǎng)景MPP（Massively Parallel Processing）數(shù)據(jù)庫(kù)，充分汲取了關(guān)系型OLAP數(shù)據(jù)庫(kù)與分布式存儲(chǔ)系統(tǒng)在大數(shù)據(jù)時(shí)代的精髓。通過(guò)不斷的改進(jìn)與優(yōu)化，它在架構(gòu)上進(jìn)行了升級(jí)，并增添了諸多創(chuàng)新功能，從而演變?yōu)橐豢铑I(lǐng)先的企業(yè)級(jí)產(chǎn)品。StarRocks致力于為用戶提供極速且統(tǒng)一的分析體驗(yàn)，能夠靈活應(yīng)對(duì)各種數(shù)據(jù)分析場(chǎng)景。它支持多種數(shù)據(jù)模型、導(dǎo)入方式，并能輕松整合及接入現(xiàn)有系統(tǒng)，如Spark、Flink、Hive和ElasticSearch等。
此外，StarRocks還兼容MySQL協(xié)議，使得用戶能夠通過(guò)MySQL客戶端及常用BI工具輕松進(jìn)行數(shù)據(jù)分析。其分布式架構(gòu)特性使得數(shù)據(jù)表能夠水平劃分并多副本存儲(chǔ)，集群規(guī)?？伸`活調(diào)整，支持高達(dá)10PB級(jí)別的數(shù)據(jù)分析。同時(shí)，MPP框架的引入使得計(jì)算能夠并行加速，而多副本設(shè)計(jì)則提供了彈性容錯(cuò)能力。
在技術(shù)層面，StarRocks采用關(guān)系模型和嚴(yán)格的列式存儲(chǔ)引擎，通過(guò)精妙的編碼和壓縮技術(shù)來(lái)降低讀寫(xiě)放大效應(yīng)。其向量化執(zhí)行方式能充分利用多核CPU的并行計(jì)算能力，從而顯著提升查詢性能。要實(shí)現(xiàn)這一技術(shù)，需要借助CPU的SIMD指令集，這是一種能夠在CPU寄存器層面實(shí)現(xiàn)數(shù)據(jù)并行操作的技術(shù)。
什么是StarRocks？
StarRocks是新一代極速全場(chǎng)景MPP數(shù)據(jù)庫(kù)（高并發(fā)數(shù)據(jù)庫(kù)）。
StarRocks充分吸收關(guān)系型OLAP數(shù)據(jù)庫(kù)和分布式存儲(chǔ)系統(tǒng)在大數(shù)據(jù)時(shí)代的優(yōu)秀研究成果。
1.可以在Spark和Flink里面處理數(shù)據(jù)，然后將處理完的數(shù)據(jù)寫(xiě)到StarRocks里面。
2.可以實(shí)現(xiàn)將數(shù)據(jù)從Hadoop倒入到StarRocks里面去，也可以將StarRocks的數(shù)據(jù)倒入到Hadoop里面，都是可以實(shí)現(xiàn)的。
3.可以對(duì)接ES數(shù)據(jù)庫(kù)（ElasticSearch）。
4.StarRocks兼容MySQL的協(xié)議，可以通過(guò) MySQL的客戶端 和 常用BI工具 對(duì)接StarRocks來(lái)進(jìn)行數(shù)據(jù)分析。
5.StarRocks采用分布式架構(gòu)，對(duì)數(shù)據(jù)表進(jìn)行水平劃分并且以多副本存儲(chǔ)，集群規(guī)?？梢造`活伸縮，能夠支持10PB級(jí)別的數(shù)據(jù)分析，支持MPP框架，并行加速計(jì)算，支持多副本，具有彈性容錯(cuò)能力。
StarRocks適合什么場(chǎng)景？
1.OLAP多維分析：用戶行為分析，用戶畫(huà)像，財(cái)務(wù)報(bào)表，系統(tǒng)監(jiān)控分析。
2.實(shí)時(shí)數(shù)據(jù)分析：電商數(shù)據(jù)分析，直播質(zhì)量分析，物流運(yùn)單分析，廣告投放分析。
3.高并發(fā)查詢：廣告主表分析，Dashboard多頁(yè)面分析。
4.統(tǒng)一分析：通過(guò)使用一套系統(tǒng)解決上述場(chǎng)景，降低系統(tǒng)復(fù)雜度和多技術(shù)棧開(kāi)發(fā)成本。
StarRocks基本概念：
1.FE：FrondEnd是StarRocks的前端節(jié)點(diǎn)，負(fù)責(zé)管理元數(shù)據(jù)，負(fù)責(zé)與客戶端連接，進(jìn)行查詢規(guī)劃，查詢調(diào)度等工作。
2.BE：BackEnd時(shí)StarRocks的后端節(jié)點(diǎn)，負(fù)責(zé)數(shù)據(jù)存儲(chǔ)，計(jì)算執(zhí)行，以及Compaction，副本管理等工作。
3.Broker：Broker并不是必須出現(xiàn)的，當(dāng)StarRocks和HDFS進(jìn)行交互的時(shí)候（也就是數(shù)據(jù)從HDFS到StarRocks中 和 數(shù)據(jù)從StarRocks中到HDFS里面），那么StaRocks負(fù)責(zé)這個(gè)過(guò)程的中轉(zhuǎn)服務(wù)，輔助提供導(dǎo)入導(dǎo)出功能。
4.StarRocksManager：StarRocks的可視化工具，提供StarRocks的集群管理，在線查詢，故障查詢，監(jiān)控報(bào)警的可視化工具。
5.Tablet：StarRocks中表的邏輯分片，也是StarRocks中副本管理的基本單位，每個(gè)表根據(jù)分區(qū)和分桶機(jī)制被劃分成多個(gè)Tablet存儲(chǔ)在不同BE節(jié)點(diǎn)上。
StarRocks系統(tǒng)架構(gòu)：
FE：
1.接受MySQL客戶端的連接，解析并且執(zhí)行SQL語(yǔ)句。
2.管理元數(shù)據(jù)，執(zhí)行SQL DDL命令，用CataLog記錄庫(kù)，表，分區(qū)，tablet副本等信息。
3.FE高可用部署，使用 復(fù)制協(xié)議選主 和 主從同步 元數(shù)據(jù)，所有的元數(shù)據(jù)修改操作，都有FE的leader節(jié)點(diǎn)完成，F(xiàn)E的follower節(jié)點(diǎn)可執(zhí)行讀操作。元數(shù)據(jù)的讀寫(xiě)滿足順序一致性，F(xiàn)E的節(jié)點(diǎn)數(shù)目采用2n+1，可以容忍n個(gè)節(jié)點(diǎn)故障，當(dāng)FE leader故障的時(shí)候，可以從現(xiàn)有的follower節(jié)點(diǎn)中重新選主，完成故障切換。
4.FE中的SQL Layer對(duì)用戶提交的SQL進(jìn)行解析，分析，改寫(xiě)，語(yǔ)義分析和關(guān)系代數(shù)優(yōu)化，生產(chǎn)邏輯執(zhí)行計(jì)劃。
5.FE中的Planner負(fù)責(zé)把邏輯計(jì)劃轉(zhuǎn)化為可分布式執(zhí)行的物理計(jì)劃，分發(fā)給一組BE。
6.FE監(jiān)督BE，管理BE的上下線，根據(jù)BE的存活和健康狀態(tài)，維持tablet副本的數(shù)量。
7.FE協(xié)調(diào)數(shù)據(jù)導(dǎo)入，保證數(shù)據(jù)導(dǎo)入的一致性。
BE：
1.BE管理tablet副本，tablet時(shí)table經(jīng)過(guò)分區(qū)分桶形成的子表，采用列式存儲(chǔ)。
2.BE受FE指導(dǎo)，創(chuàng)建或刪除子表。
3.BE接收FE分發(fā)的物理執(zhí)行計(jì)劃并指定BE coordinator節(jié)點(diǎn)，在BE coordinator的調(diào)度下，與其他BE worker共同協(xié)作完成執(zhí)行。
4.BE讀本地的列存儲(chǔ)引擎獲取數(shù)據(jù)，并通過(guò)索引和謂詞下沉快速過(guò)濾數(shù)據(jù)。
5.BE后臺(tái)執(zhí)行compact任務(wù)，減少查詢時(shí)的讀放大。
6.數(shù)據(jù)導(dǎo)入的時(shí)候，由FE指定BE coordinator，將數(shù)據(jù)以fanout的形式寫(xiě)入到tablet多副本所在的BE上。
StarRocks為什么快：
列式存儲(chǔ)：StarRocks中，一張表的列可以分為維度列（key列）和指標(biāo)列（value列），維度列用于分組和排序，指標(biāo)列可通過(guò)聚合函數(shù)等累加起來(lái)。StarRocks可以認(rèn)為是多維的key到多維指標(biāo)的映射。（在寫(xiě)SQL的時(shí)候最好要根據(jù)表的前綴，類似于MySQL的索引最左前綴原則）
稀疏索引：當(dāng)進(jìn)行范圍查詢時(shí)，StarRocks能夠快速定位到起始目標(biāo)行，是因?yàn)閟hortkey index（稀疏索引）。
預(yù)先聚合：StarRocks支持聚合模型，維度列取值相同數(shù)據(jù)行可合并一行，合并后數(shù)據(jù)行的維度列取值不變，指標(biāo)列的取值為這些數(shù)據(jù)行的聚合結(jié)果，用戶需要給指標(biāo)列指定聚合函數(shù)，通過(guò)預(yù)先聚合，可以加速聚合操作。
分區(qū)分桶：StarRocks的表被分為tablet，每個(gè)tablet多副本冗余存儲(chǔ)在BE上，BE和tablet的數(shù)量可以根據(jù)計(jì)算資源和數(shù)據(jù)規(guī)模而彈性伸縮，查詢時(shí)，多臺(tái)BE可并行地查找tablet快速獲取數(shù)據(jù)。而且tablet的副本可以復(fù)制和前一，增強(qiáng)了數(shù)據(jù)的可靠性，避免了數(shù)據(jù)傾斜。
列級(jí)別的索引技術(shù)：Bloomfilter可以快速判斷數(shù)據(jù)塊中不含所查找值，ZoneMap通過(guò)數(shù)據(jù)范圍快速過(guò)濾待查找值，Bitmap索引可快速計(jì)算出枚舉類型的列滿足一定條件的行。
StarRocks的4種表模型：
明細(xì)模型（Duplicate key）：關(guān)注歷史數(shù)據(jù)。
聚合模型（Aggregate key）：關(guān)注總量，平均值，最大值，最小值，計(jì)算一個(gè)統(tǒng)一的指標(biāo)。
更新模型（Unique key）：設(shè)定一個(gè)主鍵（uid），主鍵是唯一的，如果主鍵是第一次出現(xiàn)在表中，那么執(zhí)行插入操作，如果主鍵第二次出現(xiàn)在表中，那么執(zhí)行更新操作，覆蓋前一條記錄。（并不是真的覆蓋，其實(shí)也存著明細(xì)數(shù)據(jù)，只是將最新的一條記錄返回）
主鍵模型（Primary key）：主鍵模型相當(dāng)于是更新模型的升級(jí)版，速度更快一些。更新模型采用Merge on Read讀時(shí)合并策略會(huì)大大限制查詢功能，在主鍵模型更好地解決了行級(jí)的更新操作。配合Flink-connector-starrocks可以完成MySQL CDC實(shí)時(shí)同步的方案。存儲(chǔ)引擎會(huì)為主鍵建立索引，導(dǎo)入數(shù)據(jù)時(shí)會(huì)把索引加載到內(nèi)存中，所以主鍵模型對(duì)內(nèi)存的要求更高。真正保證每個(gè)主鍵只有一條數(shù)據(jù)存在。
各自適用場(chǎng)景：
1.明細(xì)模型：建表的時(shí)候注意設(shè)置排序列（duplicate key）
關(guān)注歷史明細(xì)數(shù)據(jù)。
2.聚合模型：建表的時(shí)候注意設(shè)置聚合列（ distributed by hash(site_id) ）
業(yè)務(wù)方進(jìn)行查詢?yōu)閰R總類查詢，比如sum，count，max。
不需要查看明細(xì)數(shù)據(jù)。
老數(shù)據(jù)不會(huì)被頻繁修改，只會(huì)追加和新增。
3.更新模型：建表的時(shí)候注意設(shè)置UNIQUE KEY 唯一列(create_time,order_id)
數(shù)據(jù)需要進(jìn)行更新，比如拉鏈表。
已經(jīng)寫(xiě)入的數(shù)據(jù)有大量的更新需求。（比如電商場(chǎng)景中，訂單的狀態(tài)經(jīng)常會(huì)發(fā)生變化，沒(méi)必要用明細(xì)表記錄變化趨勢(shì)，使用更新模型記錄最新的狀態(tài)即可）
需要進(jìn)行實(shí)時(shí)數(shù)據(jù)分析。
4.主鍵模型：建表的時(shí)候注意PRIMARY KEY主鍵列（user_id）
數(shù)據(jù)冷熱特征：只有最近幾天的數(shù)據(jù)才需要修改，老的冷數(shù)據(jù)很少需要修改，比如訂單數(shù)據(jù)，老的訂單完成后就不再更新，并且分區(qū)是按天進(jìn)行分區(qū)的，那么在導(dǎo)入數(shù)據(jù)時(shí)歷史分區(qū)的數(shù)據(jù)的主鍵就不會(huì)被加載，也就不會(huì)占用內(nèi)存了，內(nèi)存中僅會(huì)加載近幾天的索引。
大寬表（數(shù)百列數(shù)千列）：主鍵只占整個(gè)數(shù)據(jù)的很小一部分，內(nèi)存開(kāi)銷比較低。比如用戶狀態(tài)/畫(huà)像表，雖然列非常多，但總的用戶數(shù)量不大，主鍵索引內(nèi)存占用相對(duì)可控。
StarRocks排序列：
明細(xì)模型中的排序列可以理解成是 DUPLICATED KEY
聚合模型中的排序列可以理解成是 AGGREGATE KEY
更新模型中的排序列可以理解成是UNIQUE KEY
主鍵模型中的排序列可以理解成是PRIMARY KEY
排序列的設(shè)定順序必須和建表語(yǔ)句的字段順序一樣，如果想使用到排序列那么必須要按照類似于MySQL的索引最左前綴原則，設(shè)定where條件。
使用排序鍵的本質(zhì)其實(shí)就是在進(jìn)行二分查找，所以排序列指定的越多，那么消耗的內(nèi)存也會(huì)越大，StarRocks為了避免這種情況發(fā)生也對(duì)排序鍵做了限制：
1.排序鍵的列只能是建表字段的前綴。
2.排序鍵的列數(shù)不能超過(guò)3.
3.字節(jié)數(shù)不超過(guò)36字節(jié)。
4.不包含F(xiàn)LOAT/DOUBLE類型的列。
5.Varchar類型列只能出現(xiàn)一次，并且是末尾位置。
物化視圖：Materialized View（MVs）物化視圖
在基于維度進(jìn)行分析的時(shí)候，需要使用物化視圖。
StarRocks中Bitmap索引：
BitMap索引利用位數(shù)組（bit array）來(lái)表示數(shù)據(jù)集中某個(gè)屬性的所有可能值是否出現(xiàn)，每個(gè)位對(duì)應(yīng)數(shù)據(jù)表中的一行記錄，如果該位為1，則表示該行記錄具有指定的屬性值；如果為0，則表示不具備。這種結(jié)構(gòu)非常適合于 處理布爾型查詢 或者 枚舉類型比較少 的列查詢，比如性別。
BitMap在一些場(chǎng)景下表現(xiàn)的比較優(yōu)秀，但是同樣也存在著局限性：
1.內(nèi)存消耗：BitMap索引會(huì)占據(jù)比較大的內(nèi)存空間。
2.更新成本：當(dāng)數(shù)據(jù)插入，刪除或者更新的時(shí)候，對(duì)應(yīng)的位圖需要維護(hù)，會(huì)產(chǎn)生開(kāi)銷。
總結(jié)：最適用的場(chǎng)景是針對(duì)于低基數(shù)（列中不同值的數(shù)量很少），會(huì)展現(xiàn)出更高的優(yōu)化能力。
StarRocks中布隆過(guò)濾器：
Bloom Filter（布隆過(guò)濾器），是用于快速地判斷某個(gè)元素是否在一個(gè)集合中的數(shù)據(jù)結(jié)構(gòu)，優(yōu)點(diǎn)是空間效率和時(shí)間效率都很高，缺點(diǎn)是有一定的誤判率。就是說(shuō)，如果布隆過(guò)濾器說(shuō)一個(gè)元素不在集合中，那它確實(shí)不在；但如果說(shuō)一個(gè)元素可能在這個(gè)集合中，這個(gè)結(jié)論也不一定是正確的。
工作原理：布隆過(guò)濾器 由一個(gè) 位數(shù)組（二進(jìn)制向量） 和 一系列哈希函數(shù) 組成。在初始化的階段，所有的位都是0。當(dāng)一個(gè)元素被插入到布隆過(guò)濾器中時(shí)，會(huì)被每一個(gè)哈希函數(shù)處理，每個(gè)哈希函數(shù)都會(huì)產(chǎn)生一個(gè)位數(shù)組的索引，然后相應(yīng)位置的位會(huì)被置為1。這樣，每個(gè)元素的插入都會(huì)在位數(shù)組中留下多個(gè)標(biāo)記。檢查一個(gè)元素是否在集合中的時(shí)候，也是使用同樣的哈希函數(shù)計(jì)算出多個(gè)索引的位置，如果所有這些位置的位都是1，那么可能在集合中，如果任何一位是0，那么就可以確定不在集合中。
（如果布隆過(guò)濾器已經(jīng)判斷出集合中不存在指定的值，就不需要讀取數(shù)據(jù)文件。
如果布隆過(guò)濾器判斷出集合中包含指定的值，就需要讀取數(shù)據(jù)文件確認(rèn)目標(biāo)值是否存在。
另外，Bloom Filter索引無(wú)法確定具體是哪一行數(shù)據(jù)具有該指定的值）
在StarRocks中的應(yīng)用：
減少磁盤(pán)I/O：在執(zhí)行查詢時(shí)，布隆過(guò)濾器可以先于實(shí)際數(shù)據(jù)讀取之前被查詢，用于快速排除那些肯定不包含查詢結(jié)果的數(shù)據(jù)塊，從而減少不必要的磁盤(pán)讀取操作，提高查詢效率。
分區(qū)剪枝（partition pruning）：在分布式系統(tǒng)中，布隆過(guò)濾器可以幫助決定是否需要從特定分區(qū)或者節(jié)點(diǎn)中讀取數(shù)據(jù)，實(shí)現(xiàn)查詢的分區(qū)剪枝，減少網(wǎng)絡(luò)傳輸和計(jì)算資源的消耗。
動(dòng)態(tài)調(diào)整：StarRocks的布隆過(guò)濾器支持動(dòng)態(tài)調(diào)整其誤報(bào)率，以適應(yīng)不同查詢場(chǎng)景的需求。通過(guò)調(diào)整哈希函數(shù)的數(shù)量和位數(shù)組的大小，可以在誤報(bào)率和存儲(chǔ)空間之間找到平衡。
通過(guò)在建表的時(shí)候設(shè)定 PROPERTIES("bloom_filter_columns"="event_type,sex");
注意事項(xiàng)：
1.不支持對(duì)Tinyint，F(xiàn)loat，Double類型的列建Bloom Filter索引。
2.Bloom Filter索引只對(duì) 'in' 和 '=' 過(guò)濾查詢有加速效果。
3.如果要查看某個(gè)查詢是否命中了Bloom Filter索引，可以通過(guò)查詢的Profile信息查看（TODO：加上查看Profile的鏈接）。
StarRocks的數(shù)據(jù)導(dǎo)入：
| StarRocks的數(shù)據(jù)導(dǎo)入方式 | 原理和場(chǎng)景 |
| Stream Load | 支持從本地直接導(dǎo)入數(shù)據(jù)，支持CSV格式，數(shù)據(jù)量在10G以下。 原理：Stream Load中，用戶通過(guò)HTTP協(xié)議提交導(dǎo)入命令，提交到FE節(jié)點(diǎn)，F(xiàn)E節(jié)點(diǎn)則會(huì)通過(guò)HTTP重定向指令請(qǐng)求轉(zhuǎn)發(fā)給某一個(gè)BE節(jié)點(diǎn)，用戶也可以直接提交導(dǎo)入命令指定BE節(jié)點(diǎn)。 |
| Broker Load | 支持從HDFS，S3等外部存儲(chǔ)系統(tǒng)導(dǎo)入數(shù)據(jù)，支持CSV，ORCFile，Parquet等文件格式，數(shù)據(jù)量在幾十GB到上百GB級(jí)別。 |
| Rountine Load | StarRocks通過(guò)這種方式支持從Kafka持續(xù)不斷的導(dǎo)入數(shù)據(jù)，并且支持通過(guò)SQL控制導(dǎo)入任務(wù)的暫停，重啟，停止。將Job提交給FE，拆分成多個(gè)task，將task并行的向BE（StarRocks）里面寫(xiě) |
| Spark Load | |
| Insert into | 只是通過(guò)寫(xiě)SQL來(lái)操作。 |
| Flink Connector | |
| Datax Writer |
Colocate join：
colocate join可以避免數(shù)據(jù)網(wǎng)絡(luò)傳輸開(kāi)銷，核心思想是將同一個(gè)Colocation Group中表采用一致的分桶鍵，一致的副本數(shù)量和一致副本放置方式。因此如果join列分桶鍵一致，則計(jì)算節(jié)點(diǎn)只需做本地join即可，無(wú)須從其他節(jié)點(diǎn)獲取數(shù)據(jù)，從而規(guī)避網(wǎng)絡(luò)shuffle的過(guò)程。
可以通過(guò)設(shè)置PROPERTIES（"colocate_with" = "group"）,如果colocate：true，那么就是得到了colocate join優(yōu)化，如果colocate：false，那么就是沒(méi)有得到colocate join優(yōu)化（可能會(huì)存在shuffle）。
StarRocks外部表：
到此這篇關(guān)于StarRocks數(shù)據(jù)庫(kù)詳解(什么是StarRocks)的文章就介紹到這了,更多相關(guān)StarRocks詳解內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！
相關(guān)文章
作為開(kāi)發(fā)人員,我們免不了與sql打交道,有些sql可能在業(yè)務(wù)的最開(kāi)始,執(zhí)行是毫無(wú)問(wèn)題的,但是隨著業(yè)務(wù)量的提升以及業(yè)務(wù)復(fù)雜度的加 深,可能之前的sql就會(huì)需要優(yōu)化了,下面這篇文章主要給大家介紹了關(guān)于一次SQL優(yōu)化的實(shí)戰(zhàn)記錄,需要的朋友可以參考下2022-07-07
一篇文章教會(huì)你使用gs_restore導(dǎo)入數(shù)據(jù)
gs_restore是GaussDB(DWS)提供的針對(duì)gs_dump導(dǎo)出數(shù)據(jù)的導(dǎo)入工具,下面這篇文章主要給大家介紹了關(guān)于如何通過(guò)一篇文章教會(huì)你使用gs_restore導(dǎo)入數(shù)據(jù)的相關(guān)資料,需要的朋友可以參考下2022-09-09
這篇文章主要介紹了Navicat使用快速入門(mén)教程，文中通過(guò)示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧2020-11-11
SQL中NTEXT字段內(nèi)容顯示<long text>的原因
SQL中NTEXT字段內(nèi)容顯示<long text>的原因...2007-03-03
大家好，本篇文章主要講的是聚合函數(shù)和group by的關(guān)系詳解，感興趣的同學(xué)趕快來(lái)看一看吧，對(duì)你有幫助的話記得收藏一下2022-01-01
免費(fèi)開(kāi)源數(shù)據(jù)庫(kù):SQLite、MySQL和PostgreSQL的優(yōu)缺點(diǎn)
對(duì)于處理大規(guī)模數(shù)據(jù)和高并發(fā)訪問(wèn)的場(chǎng)景,MySQL和PostgreSQL更適合,SQLite在小型應(yīng)用程序或嵌入式設(shè)備中是一種輕量級(jí)、簡(jiǎn)單和易于使用的選擇,根據(jù)具體的應(yīng)用需求和場(chǎng)景特點(diǎn),選擇合適的開(kāi)源關(guān)系型數(shù)據(jù)庫(kù)可以提供更好的性能、可擴(kuò)展性和靈活性2024-02-02
關(guān)于ADOX的相關(guān)知識(shí)...2006-12-12
這篇文章主要介紹了使用navicat導(dǎo)入sql文件的方法步驟，文中通過(guò)示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧2020-11-11
時(shí)序數(shù)據(jù)庫(kù)VictoriaMetrics源碼解析之寫(xiě)入與索引
這篇文章主要為大家介紹了VictoriaMetrics時(shí)序數(shù)據(jù)庫(kù)的寫(xiě)入與索引源碼解析，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪2023-05-05
Hive數(shù)據(jù)去重的兩種方式?(distinct和group?by)
數(shù)據(jù)庫(kù)中表存在重復(fù)數(shù)據(jù),需要清理重復(fù)數(shù)據(jù),下面這篇文章主要給大家介紹了關(guān)于Hive數(shù)據(jù)去重的兩種方式,文中通過(guò)實(shí)例代碼介紹的非常詳細(xì),需要的朋友可以參考下2023-01-01