⑴ 如何評價SequoiaDB巨杉資料庫
equoiaDB巨杉資料庫 是國內領先的新一代分布式資料庫廠商。
主要產品SequoiaDB是國內唯一一款企業級的新一代分布式、標准化Newsql資料庫。作為商業化的資料庫產品，現已開源。同時也提供了包括企業數據融合和再加工、非結構化數據管理平台、大數據管理平台在內的多個企業級大數據解決方案。
SequoiaDB巨杉資料庫也於近期發布了SequoiaDB 2.0企業版，新版本加入了SQL2003支持、雙引擎核心存儲、雙活機制等，在企業級功能上超越矽谷同類產品。作為Spark全球的發行商之一，巨杉在2.0時代將提供高並發實時計算、高吞吐量批處理分析、以及在線流處理計算等一系列企業級解決方案，SequoiaDB巨杉資料庫平台可以幫助企業快速地進行跨系統的數據融和、提煉和再加工。
近期，在當前的資本寒冬之下，巨杉於近期獲得了DCM領投的近億元B輪融資。這體現了投資界對於這家務實的大數據基礎軟體公司發展的一致看好，而此次融資也成為國內新一代分布式資料庫領域最大的一筆投融資。
⑵ 如何實現一個NEWSQL資料庫
我想統計資料庫中今天，發帖最多的人。
select * from user order by s_count desc
user是你的用戶表，s_count是用戶表中的發貼數量欄位
然後直接取出記錄的第一條就是法帖最多的
發帖最多的前10個人，並從多到少，進行排序
select top 10 from user order by s_count desc,id asc
id是你的用戶表主鍵id.
⑶ newsql和nosql的區別
你說的很亂，oracle是關系型資料庫，mysql也是，兩者並存甚至oracle要強勢些。至於非關系型資料庫，oracle也是有優勢的，尤其在於數據量小的時候，特別明顯。另外，oracle近幾年也退出了很多框架來利用分布式存儲來實現大數據，其本身也在不斷推陳出新，取代是不太可能的
⑷ 資料庫為什麼要分庫分表
1 基本思想之什麼是分庫分表？
從字面上簡單理解，就是把原本存儲於一個庫的數據分塊存儲到多個庫上，把原本存儲於一個表的數據分塊存儲到多個表上。
2 基本思想之為什麼要分庫分表？
數
據庫中的數據量不一定是可控的，在未進行分庫分表的情況下，隨著時間和業務的發展，庫中的表會越來越多，表中的數據量也會越來越大，相應地，數據操作，增
刪改查的開銷也會越來越大；另外，由於無法進行分布式式部署，而一台伺服器的資源（CPU、磁碟、內存、IO等）是有限的，最終資料庫所能承載的數據量、
數據處理能力都將遭遇瓶頸。
3 分庫分表的實施策略。
分庫分表有垂直切分和水平切分兩種。
3.1
何謂垂直切分，即將表按照功能模塊、關系密切程度劃分出來，部署到不同的庫上。例如，我們會建立定義資料庫workDB、商品資料庫payDB、用戶數據
庫userDB、日誌資料庫logDB等，分別用於存儲項目數據定義表、商品定義表、用戶數據表、日誌數據表等。
3.2
何謂水平切分，當一個表中的數據量過大時，我們可以把該表的數據按照某種規則，例如userID散列，進行劃分，然後存儲到多個結構相同的表，和不同的庫
上。例如，我們的userDB中的用戶數據表中，每一個表的數據量都很大，就可以把userDB切分為結構相同的多個userDB：part0DB、
part1DB等，再將userDB上的用戶數據表userTable，切分為很多userTable：userTable0、userTable1等，
然後將這些表按照一定的規則存儲到多個userDB上。
3.3 應該使用哪一種方式來實施資料庫分庫分表，這要看資料庫中數據量的瓶頸所在，並綜合項目的業務類型進行考慮。
如果資料庫是因為表太多而造成海量數據，並且項目的各項業務邏輯劃分清晰、低耦合，那麼規則簡單明了、容易實施的垂直切分必是首選。
而
如果資料庫中的表並不多，但單表的數據量很大、或數據熱度很高，這種情況之下就應該選擇水平切分，水平切分比垂直切分要復雜一些，它將原本邏輯上屬於一體
的數據進行了物理分割，除了在分割時要對分割的粒度做好評估，考慮數據平均和負載平均，後期也將對項目人員及應用程序產生額外的數據管理負擔。
在現實項目中，往往是這兩種情況兼而有之，這就需要做出權衡，甚至既需要垂直切分，又需要水平切分。我們的游戲項目便綜合使用了垂直與水平切分，我們首先對資料庫進行垂直切分，然後，再針對一部分表，通常是用戶數據表，進行水平切分。
4 分庫分表存在的問題。
4.1 事務問題。
在執行分庫分表之後，由於數據存儲到了不同的庫上，資料庫事務管理出現了困難。如果依賴資料庫本身的分布式事務管理功能去執行事務，將付出高昂的性能代價；如果由應用程序去協助控制，形成程序邏輯上的事務，又會造成編程方面的負擔。
4.2 跨庫跨表的join問題。
在執行了分庫分表之後，難以避免會將原本邏輯關聯性很強的數據劃分到不同的表、不同的庫上，這時，表的關聯操作將受到限制，我們無法join位於不同分庫的表，也無法join分表粒度不同的表，結果原本一次查詢能夠完成的業務，可能需要多次查詢才能完成。
4.3 額外的數據管理負擔和數據運算壓力。
額
外的數據管理負擔，最顯而易見的就是數據的定位問題和數據的增刪改查的重復執行問題，這些都可以通過應用程序解決，但必然引起額外的邏輯運算，例如，對於
一個記錄用戶成績的用戶數據表userTable，業務要求查出成績最好的100位，在進行分表之前，只需一個order
by語句就可以搞定，但是在進行分表之後，將需要n個order
by語句，分別查出每一個分表的前100名用戶數據，然後再對這些數據進行合並計算，才能得出結果。
⑸ 現在國產資料庫有哪些品牌
據我網上找的資料,目前國產資料庫主要有3個1、南京大學通用newsql資料庫——gbase2、達夢新1代雲資料庫——dm73、人大金倉分析型資料庫kingbasees但個人觀點,在國外多個知名商業化資料庫oracle,sqlserver,db2等和開源的資料庫如mysql,postgresql等眼前,這些基本沒有甚麼市場
⑹ NewSQL為何使傳統關系資料庫黯然失色
傳統資料庫仍舊會有一席之地，至於NewSQL的優勢又是什麼，簡單和大家說說：
首先關於「中間件+關系資料庫分庫分表」算不算NewSQL分布式資料庫問題，國外有篇論文pavlo-newsql-sigmodrec，如果根據該文中的分類，Spanner、TiDB、OB算是第一種新架構型，Sharding-Sphere、Mycat、DRDS等中間件方案算是第二種（文中還有第三種雲資料庫，本文暫不詳細介紹）。
基於中間件（包括SDK和Proxy兩種形式）+傳統關系資料庫（分庫分表）模式是不是分布式架構？我覺得是的，因為存儲確實也分布式了，也能實現橫向擴展。但是不是「偽」分布式資料庫？從架構先進性來看，這么說也有一定道理。
「偽」主要體現在中間件層與底層DB重復的SQL解析與執行計劃生成、存儲引擎基於B+Tree等，這在分布式資料庫架構中實際上冗餘低效的。為了避免引起真偽分布式資料庫的口水戰，本文中NewSQL資料庫特指這種新架構NewSQL資料庫。
NewSQL資料庫相比中間件+分庫分表的先進在哪兒？畫一個簡單的架構對比圖：
- 傳統資料庫面向磁碟設計，基於內存的存儲管理及並發控制，不如NewSQL資料庫那般高效利用；
- 中間件模式SQL解析、執行計劃優化等在中間件與資料庫中重復工作，效率相比較低；
- NewSQL資料庫的分布式事務相比於XA進行了優化，性能更高；
- 新架構NewSQL資料庫存儲設計即為基於paxos（或Raft）協議的多副本，相比於傳統資料庫主從模式（半同步轉非同步後也存在丟數問題），在實現了真正的高可用、高可靠（RTO<30s，RPO=0）；
- NewSQL資料庫天生支持數據分片，數據的遷移、擴容都是自動化的，大大減輕了DBA的工作，同時對應用透明，無需在SQL指定分庫分表鍵。
⑺ Oracle是否有被HADLOOP，NOSQL，NEWSQL，MYSQL，OCEANBASE取代的可能
hadoop：Hadoop是一個由Apache基金會所開發的分布式系統基礎架構。多用了存在數量巨大的小文件、視頻等；
NOSQL：泛指非關系型的資料庫。
NewSQL 是對各種新的可擴展/高性能資料庫的簡稱，這類資料庫不僅具有NoSQL對海量數據的存儲管理能力，還保持了傳統資料庫支持ACID和SQL等特性。
MYSQL：被Oracle收購
OCEANBASE：OceanBase是一個支持海量數據的高性能分布式資料庫系統，實現了數千億條記錄、數百TB數據上的跨行跨表事務，由淘寶核心系統研發部、運維、DBA、廣告、應用研發等部門共同完成。
總之，各有不同特點。
⑻ C#創建新的SQL資料庫
1、建立連接
System.Data.SqlClient.SqlConnection oConn=new System.Data.SqlClient.SqlConnection("data source="+this.DbServer.Text+";initial catalog=master;user id="+this.UserId.Text+";password="+this.Password.Text);
2、//建立資料庫
System.Data.SqlClient.SqlCommand oComm=oConn.CreateCommand();
oComm.CommandText="CREATE DATABASE "+this.DBName.Text ;
try
{
oComm.ExecuteNonQuery();
}
catch
{
System.Windows.Forms.MessageBox.Show(this,"建立資料庫出錯，請手工建立指定的資料庫","信息提示",System.Windows.Forms.MessageBoxButtons.OK);
oComm.Dispose();
3、轉換到新建的資料庫
oConn.ChangeDatabase(this.DBName.Text);
4、建立其他對象
oCommand.CommandText="if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[AddAnalyzeRecord]') and OBJECTPROPERTY(id, N'IsProcere') = 1)\n";
oCommand.CommandText+="drop procere [dbo].[AddAnalyzeRecord]\n";
oCommand.ExecuteNonQuery();
oCommand.CommandText="\n";
oCommand.CommandText+="if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[AddVisitErrorLog]') and OBJECTPROPERTY(id, N'IsProcere') = 1)\n";
oCommand.CommandText+="drop procere [dbo].[AddVisitErrorLog]\n";
oCommand.ExecuteNonQuery();
oCommand.CommandText="\n";
oCommand.CommandText+="if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[AddVisitLog]') and OBJECTPROPERTY(id, N'IsProcere') = 1)\n";
oCommand.CommandText+="drop procere [dbo].[AddVisitLog]\n";
oCommand.ExecuteNonQuery();
oCommand.CommandText="\n";
oCommand.CommandText+="if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[AnalyzeRecord]') and OBJECTPROPERTY(id, N'IsUserTable') = 1)\n";
oCommand.CommandText+="drop table [dbo].[AnalyzeRecord]\n";
oCommand.ExecuteNonQuery();
oConn.Close();
oConn.Dispose();
}
⑼ 如何使用HBase構建NewSQL
目前主流的資料庫或者NoSQL要麼在CAP裡面選擇AP，比較典型的例子是Cassandra，要麼選擇CP比如HBase，這兩個是目前用得非
常多的NoSQL的實現。我們的價值觀一定認為未來是分布式的，一定是盡量傾向於全部都擁有，大部分情況下取捨都是HA，主流的比較頂級的資料庫都會選擇
C，分布式系統一定逃不過P，所以A就只能選擇HA。現在主要領域是資料庫的開發，完全分布式，主要方向和谷歌的F1方向非常類似。
目前看NewSQL代表未來(Google Spanner、F1、FoundationDB)，HBase在國內有六個Committer，在目
前主流的開源資料庫裡面幾乎是最強的陣容。大家選型的時候會有一個猶豫，到底應該選擇HBase還是選Cassandra。根據應用場景，如果需要一致
性，HBase一定是你最好的選擇，我推薦HBase。它始終保持強一致，我們非常喜歡一致性，喪失一致性的時候有些錯誤會特別詭異，很難查。對於
Push-down特性的設計其實比較好，全局上是一個巨大的分布式資料庫，但是邏輯上是分成了一個個Region，Region在哪台機器上是明確的。
比如要統計記錄的條數，假設數據分布在整個系統裡面，對數十億記錄做一個求和操作，就是說不同的機器上都要做一個sum，把條件告訴他要完成哪些任務，他給你任務你再匯總，這是典型的分布式的 MPP，做加速的時候是非常有效的。
2015年HBaseConf 上面有一句總結: 「Nothing is hotter than SQL-on-
Hadoop, and now SQL-
on- HBase is fast approaching equal hotness status」， 實際上SQL-on-HBase 也是非
常火。因為 Schema Less 沒有約束其實是很嚇人的一件事情，當然沒有約束也比較爽，就是後期維護十分痛苦，規模進一步擴大了之後又需要遷移
到 SQL。
現在無論從品質還是速度上要求已經越來越高，擁有SQL的同時還希望有ACID的東西(OLAP一般不追求一致性)。所以TiDB在設計時就強調這
樣的特點：始終保持分布式事務的支持，兼容MySQL協議。無數公司在SQL遇到Scale問題的時候很痛苦地做出了選擇，比如遷移到
HBase，Cassandra
MongoDB已經看過太多的公司做這種無比痛苦的事情，現在不用痛苦了，直接遷過來，直接把數據導進來就OK了。TiDB最重要的是關注OLTP，對於
互聯網業務來說通常是在毫秒級內就需要返回一個結果。
我們到目前為止開發了六個月，開源了兩個月。昨天晚上TiDB達到了第一個Alpha的階段，現在可以擁有一個強大的資料庫：支持分布式事務，始終
保持同步的復制，強大的按需Scale能力，無阻塞的Schema變更。發布第一個Alpha版本的時候以前的質疑都會淡定下來，因為你可以閱讀每一行代
碼，體驗每個功能。選擇這個領域也是非常艱難的決定，實在太Hardcore了，當初Google Spanner也做了5年。不過我們是真愛，我們就是
技術狂，就是要解決問題，就是要挑大家最頭痛的問題去解決。好在目前阿里的OceanBase給我們服了顆定心丸，大家也不會質疑分布式關系型資料庫是否
可行。