在PyCon上有童鞋提供了一個類似概念的分享，不過不大適合一般類型的互聯網項目，感覺有點過于另類。不過我實現這個方案是在看到PyCon的分享之前。算是同樣的訴求不同的實現方式吧。且我這里只是實現了一個數據訪問的組件而不是Server。

首先本文的方法來自FriendFeed分享的如何使用MySQL數據庫的分享。簡而言之就是把Python對象直接dumps后zip壓縮存儲在MySQL一個字段里。這樣不就Schemaless了么？存什么數據類型，類什么結構，MySQL都不需要知道，加個屬性什么的都不需要修改數據庫表結構，對于業務快速變更、快速增長的互聯網業務來說再合適不過了。訪問對象直接通過主鍵查詢，快速直接。but，查詢怎么辦？有的童鞋可能會問。OK，查詢這事得分兩說，如果是簡單的檢索，可以通過建索引表的方式來解決，或者呢用外部的索引，比如lucent，還能全文檢索哦。現在而今眼目下我實現了索引表索引的方式，因為外部的索引方式比較千奇百怪，所以如果需要可以根據具體情況自己來寫一個，反正實現相應的幾個方法就行。

直接上一個例子來說明。假設要實現一個blog，需要存blog的信息，先定義一個blog的模型類(需要import什么大家自動腦補)

1 class Blog(DynamicBase):
2 title=Column(unicode,max_length=200)
3 content=Column(unicode)
4 post_date=Column(datetime.datetime,db_index=True)
5 auther=FkColumn(User)
6 class Meta:
7 table_name="blogs"
8 connection=connections[DB]

這個connection是因為我還沒想好如何能無縫結合到Django中又能兼顧脫離Django獨立使用的暫時措施，完成版會去掉

如果在使用django的話只需要 python manage.py shell 然后 Blog.objects.create_table()

這個時候會自動創建模型定義的表和索引表

數據表 blogs：

CREATE TABLE `blogs` (
`id` int(11) NOT NULL,
`object` varbinary(20000) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

?同時建立兩個索引表

CREATE TABLE `blog_idx_post_date` (
`id` int(10) unsigned NOT NULL,
`post_date` DATETIME NOT NULL,
PRIMARY KEY (`id`),
INDEX `idx_blogs_by_post_date` (`post_date`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

?

CREATE TABLE `blog_idx_auther` (
`id` int(10) unsigned NOT NULL,
`auther` INT NOT NULL,
PRIMARY KEY (`id`),
INDEX `idx_blogs_by_auther` (`auther`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

?

這個時候，可以通過 Blog.objects.create(title=u"標題",content=u"內容",post_date=datetime.datetime.now(),auther=user) 或者Blog.objects.create(title=u"標題",content=u"內容",post_date=datetime.datetime.now(),auther=user.id)

就能夠創建一個Blog的對象。這個時候blogs表和兩個索引表都會插入數據。不過blogs表中的object列是人類無法理解的火星文..........

通過id直接獲取對象 ?Blog.objects.get(1),根據索引獲取 ?Blog.objects.auther.query(auther=user.id) 或者??Blog.objects.auther.query(auther=user)

這個會生成SQL，SELECT `id` FROM ?`blog_idx_auther` WHERE `auther`=%s 然后取出match到對象的id列表，然后遍歷id列表，通過?Blog.objects.get(id)獲得的對象列表。

Blog.objects.get(id)的時候是有對象緩存的（現階段通過redis實現），所以經過測試，速度是靠譜的。而相對MangoDB來說，MySQL的數據存儲也更加靠譜一點，所以相比換現在而今眼目下還不怎么靠譜的mangodb來作為主存儲來說，基于MySQL的Schemaless方案還是相對靠譜的。

?

由于現在這個東西還是處于在項目中孵化的階段還沒有能夠達到可以獨立開源出來供大家娛樂的程度，所以請大家對這個方案多提意見建議咯，源代碼估計能夠在春節后達到能夠公布出來見人的階段?

總結

以上是生活随笔為你收集整理的用MySQL数据库来支持Schemaless的数据库存储方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。