f***c
发帖数: 338 | 1 【 以下文字转载自 Database 讨论区 】
发信人: franc (笨◎), 信区: Database
标 题: 求推荐database的软件
发信站: BBS 未名空间站 (Sun Sep 22 02:22:51 2013, 美东)
需求其实也很简单：
在一个局域网中有多台机器分别采集不同数据<测量对象有些是相同，但也些是不同的>
，想通过某一个database软件将这些数据汇总到一台机器上，然后进行query， report
的处理。
编程有Python，JavaScript的背景。
谢谢。 |
z****e
发帖数: 54598 | |
c***d
发帖数: 996 | 3 主要看对实时性的要求和data integrity的要求啦。 要是都没什么要求直接写文件好
了。
的>
report
【在 f***c 的大作中提到】
: 【 以下文字转载自 Database 讨论区 】
: 发信人: franc (笨◎), 信区: Database
: 标 题: 求推荐database的软件
: 发信站: BBS 未名空间站 (Sun Sep 22 02:22:51 2013, 美东)
: 需求其实也很简单：
: 在一个局域网中有多台机器分别采集不同数据<测量对象有些是相同，但也些是不同的>
: ，想通过某一个database软件将这些数据汇总到一台机器上，然后进行query， report
: 的处理。
: 编程有Python，JavaScript的背景。
: 谢谢。
|
p*****2
发帖数: 21240 | |
p*****2
发帖数: 21240 | |
f***c
发帖数: 338 | 6 不大，单个文件<1M.。
每天有30多个文件。实在说不上是大数据。
本来跟老板讲些个script，每天ftp上传，然后用python parse，生成csv，用excel的
spread sheet处理。
但是老板说为了更正式些，要建立database。
谢谢。 |
z****e
发帖数: 54598 | |
f***c
发帖数: 338 | 8 讨论过mongoDB，
上周又建议用vaadin，可是本人没有Java经验。当然不介意去学。
还是想来问一下，像是我所说这个需求，哪一个更好？
【在 p*****2 的大作中提到】
: mongo吧。
|
f***c
发帖数: 338 | 9 谢谢，去做些homework去了
【在 z****e 的大作中提到】
: couchdb算了
: 用js来查询
|
z****e
发帖数: 54598 | 10 你们对consistency要求偏低
所以在cassandra, couchdb这些里面找
鉴于你对js的熟悉，couchdb所有操作都以支持js为首要目标
所以如果不是很介意couchdb的版本号的话
就用couchdb就可以了
【在 f***c 的大作中提到】
: 讨论过mongoDB，
: 上周又建议用vaadin，可是本人没有Java经验。当然不介意去学。
: 还是想来问一下，像是我所说这个需求，哪一个更好？
|
|
|
z****e
发帖数: 54598 | 11 因为你们是file system
所以比起column based的cassandra来说
还是couchdb比较合适 |
z****e
发帖数: 54598 | |
f***c
发帖数: 338 | 13 谢谢。
我对json还是蛮喜欢的。
明天去看couchDB。
【在 z****e 的大作中提到】
: 存储格式是json
: 你会js，这个应该懂
|
w********m
发帖数: 1137 | 14 mongoDB. 每个机器上建个replicate set的instance。 |
p*****2
发帖数: 21240 | 15
mongo只能写master吧？每个机器上建有意义吗？
【在 w********m 的大作中提到】
: mongoDB. 每个机器上建个replicate set的instance。
|
w********m
发帖数: 1137 | 16 local的query， report可能性能要好一点吧。其实也不懂 |
a***n
发帖数: 538 | |
b*******s
发帖数: 5216 | 18 印象中是会自己同步的
【在 p*****2 的大作中提到】
:
: mongo只能写master吧？每个机器上建有意义吗？
|
B***i
发帖数: 724 | 19 不知道楼上的为啥就是不提mysql 这个 成熟稳定，居家旅行皆宜的好东西？ |
p*****2
发帖数: 21240 | 20
感觉LZ主要是写操作吧？
【在 b*******s 的大作中提到】
: 印象中是会自己同步的
|
|
|
b*******s
发帖数: 5216 | 21 又看了下他的需求，觉得是overkill
这个用个传统的mysql就行了，用python访问
搭系统用二十分钟，写代码一天，足矣
【在 p*****2 的大作中提到】
: mongo吧。
|
z****e
发帖数: 54598 | 22 rdbms不是不可以
但是过剩了，做个insert还要思考pk是什么，将来还要建view什么的
每一个column都要定义和规范，不胜其烦
它做的东西，更像是一个分布式的file system
结合它会的技能，显然couchdb最合适
couchdb大部分时候就是用js来做各种操作
db还要sql
【在 B***i 的大作中提到】
: 不知道楼上的为啥就是不提mysql 这个 成熟稳定，居家旅行皆宜的好东西？
|
b*******s
发帖数: 5216 | 23 我觉得他就是在做一个实验室里用的东西，访问量不会大
不需要view之类，一个表就够了
就是一台机器做db host
其它采集的机器装个mysql client，简单一两条statement更新下数据
然后host上提供个简单界面就行了
【在 z****e 的大作中提到】
: rdbms不是不可以
: 但是过剩了，做个insert还要思考pk是什么，将来还要建view什么的
: 每一个column都要定义和规范，不胜其烦
: 它做的东西，更像是一个分布式的file system
: 结合它会的技能，显然couchdb最合适
: couchdb大部分时候就是用js来做各种操作
: db还要sql
|
z****e
发帖数: 54598 | 24 couchdb的存储文件可以直接用文本编辑器打开，json会js的肯定会
db一般还要下一个可视化的管理软件，如果用命令行就更痛苦
【在 b*******s 的大作中提到】
: 我觉得他就是在做一个实验室里用的东西，访问量不会大
: 不需要view之类，一个表就够了
: 就是一台机器做db host
: 其它采集的机器装个mysql client，简单一两条statement更新下数据
: 然后host上提供个简单界面就行了
|
b*******s
发帖数: 5216 | 25 他那个量，不需要那么复杂的管理，也不需要修改存储文件
就是create一个database，再建个表就够了
【在 z****e 的大作中提到】
: couchdb的存储文件可以直接用文本编辑器打开，json会js的肯定会
: db一般还要下一个可视化的管理软件，如果用命令行就更痛苦
|
z****e
发帖数: 54598 | 26 如果你图简单，更应该用nosql，而不是rdbms
nosql的各种软件就是嫌db太复杂后简化的东西
【在 b*******s 的大作中提到】
: 他那个量，不需要那么复杂的管理，也不需要修改存储文件
: 就是create一个database，再建个表就够了
|
b*******s
发帖数: 5216 | 27 nosql的配置本身一点都不简单
简单的是语法比sql简单
以及性能更好
【在 z****e 的大作中提到】
: 如果你图简单，更应该用nosql，而不是rdbms
: nosql的各种软件就是嫌db太复杂后简化的东西
|
z****e
发帖数: 54598 | 28 搞得好像db配置很简单一样
couchdb安装使用一点都不比mysql难
只会更简单
【在 b*******s 的大作中提到】
: nosql的配置本身一点都不简单
: 简单的是语法比sql简单
: 以及性能更好
|
r***o
发帖数: 1526 | 29 用MS的SQL Server 2012。一个SSIS package搞定，前台用.Net写个Web界面作数据分析
和报告也很容易 |
b*******s
发帖数: 5216 | 30 嗯，这个是比较简单
【在 z****e 的大作中提到】
: 搞得好像db配置很简单一样
: couchdb安装使用一点都不比mysql难
: 只会更简单
|
|
|
B***i
发帖数: 724 | 31 您老这不是在开玩笑吧？ 我是在想象不出来还有比mysql 更容易的东东。您老提的
couch db我听都没听说过， 我觉得support/document/trouble shooting什么的肯定比
不上mysql吧
【在 z****e 的大作中提到】
: rdbms不是不可以
: 但是过剩了，做个insert还要思考pk是什么，将来还要建view什么的
: 每一个column都要定义和规范，不胜其烦
: 它做的东西，更像是一个分布式的file system
: 结合它会的技能，显然couchdb最合适
: couchdb大部分时候就是用js来做各种操作
: db还要sql
|
z****e
发帖数: 54598 | 32 你凹凸了
现在还有人推荐mysql让我觉得很神奇
从sun被oracle收购之后，我就抛弃mysql了
说postgresql我还觉得比较不那么落伍
但是你这是不懂nosql，很明显凹凸了
couchdb用的mapreduce，webservice什么都比较好滴贴近将来的方向
要不懂这些，钱途堪忧
【在 B***i 的大作中提到】
: 您老这不是在开玩笑吧？ 我是在想象不出来还有比mysql 更容易的东东。您老提的
: couch db我听都没听说过， 我觉得support/document/trouble shooting什么的肯定比
: 不上mysql吧
|
p*****2
发帖数: 21240 | 33
couchdb要需要全放内存吧？
【在 z****e 的大作中提到】
: 你凹凸了
: 现在还有人推荐mysql让我觉得很神奇
: 从sun被oracle收购之后，我就抛弃mysql了
: 说postgresql我还觉得比较不那么落伍
: 但是你这是不懂nosql，很明显凹凸了
: couchdb用的mapreduce，webservice什么都比较好滴贴近将来的方向
: 要不懂这些，钱途堪忧
|
z****e
发帖数: 54598 | 34 couchdb最适合的一个场景就是内存比较少的地方
http://stackoverflow.com/questions/10314272/couchdb-vs-mongodb-
实际上疯狂依赖内存的db，除了mongodb，其它nosql几乎没有这样设计
mongodb真是nosql的一个奇芭
【在 p*****2 的大作中提到】
:
: couchdb要需要全放内存吧？
|
b*******s
发帖数: 5216 | 35 强调性能就得多放内存，不过最好是做成可配置的
mongo野心很大
【在 z****e 的大作中提到】
: couchdb最适合的一个场景就是内存比较少的地方
: http://stackoverflow.com/questions/10314272/couchdb-vs-mongodb-
: 实际上疯狂依赖内存的db，除了mongodb，其它nosql几乎没有这样设计
: mongodb真是nosql的一个奇芭
|
b*******s
发帖数: 5216 | 36 mongo是很奇特的一种？怪不得，nosql我就接触过mongo
【在 z****e 的大作中提到】
: couchdb最适合的一个场景就是内存比较少的地方
: http://stackoverflow.com/questions/10314272/couchdb-vs-mongodb-
: 实际上疯狂依赖内存的db，除了mongodb，其它nosql几乎没有这样设计
: mongodb真是nosql的一个奇芭
|
z****e
发帖数: 54598 | |
z****e
发帖数: 54598 | 38 如果用内存这种烧钱的方式的话
那我回去用db咯
【在 b*******s 的大作中提到】
: 强调性能就得多放内存，不过最好是做成可配置的
: mongo野心很大
|
z****e
发帖数: 54598 | 39 做得不伦不类的一个
想取代db又替代不了
典型的邯郸学步
【在 b*******s 的大作中提到】
: mongo是很奇特的一种？怪不得，nosql我就接触过mongo
|
b*******s
发帖数: 5216 | 40 我觉得他们的目标是做那种ebay，amazon级别大型电商的后台
【在 z****e 的大作中提到】
: 做得不伦不类的一个
: 想取代db又替代不了
: 典型的邯郸学步
|
|
|
z****e
发帖数: 54598 | 41 ebay不知道，但是amazon自己做db，有什么dynamo之类的东东
压根没有必要用mongodb，ebay很传统，都是j2ee那一套
随便用什么db，单论性能都不会输给无结构化的存储
实际上nosql真正强化的，也是throughput，而不是latency
单论latency，显然还是db在行，还有很多种办法来说，比如建立连接池
【在 b*******s 的大作中提到】
: 我觉得他们的目标是做那种ebay，amazon级别大型电商的后台
|
b*******s
发帖数: 5216 | 42 并不是所有大型电商的技术能力都足够强的
比如国内那个卖火车票的
【在 z****e 的大作中提到】
: ebay不知道，但是amazon自己做db，有什么dynamo之类的东东
: 压根没有必要用mongodb，ebay很传统，都是j2ee那一套
: 随便用什么db，单论性能都不会输给无结构化的存储
: 实际上nosql真正强化的，也是throughput，而不是latency
: 单论latency，显然还是db在行，还有很多种办法来说，比如建立连接池
|
g*****g
发帖数: 34805 | 43 这么点数据，上啥NoSQL，都是瞎折腾。MySQL/ProgreSQL就很好。 |
z****e
发帖数: 54598 | 44 火车票那种最适合的应该是主机，而不是什么分布式
飞机票全球就是清一色主机
【在 b*******s 的大作中提到】
: 并不是所有大型电商的技术能力都足够强的
: 比如国内那个卖火车票的
|
f***c
发帖数: 338 | 45 首先非常感谢各位的讨论。再次澄清一下俺的需求（虽然俺知道后面的讨论已经可以独
立于俺的问题来学习了），基本就是这样的：
-------------------------------------------
发信人: brainless (n/a), 信区: Programming
标 题: Re: 求推荐database的软件 (转载)
发信站: BBS 未名空间站 (Sun Sep 22 21:47:00 2013, 美东)
我觉得他就是在做一个实验室里用的东西，访问量不会大
不需要view之类，一个表就够了
就是一台机器做db host
其它采集的机器装个mysql client，简单一两条statement更新下数据
然后host上提供个简单界面就行了
------------------------------------
但是老板明确提出不要用MS的东西，而且希望是NoSQL的。
今天在带儿子的空隙看了一些couchDB和mongoDB的比较。个人目前比较倾向于couchDB。
继续在你们的讨论中学习。
谢谢各位。
【在 z****e 的大作中提到】
: python
: http://pythonhosted.org/CouchDB/index.html
|
b*******s
发帖数: 5216 | 46 mysql是oracle的
【在 f***c 的大作中提到】
: 首先非常感谢各位的讨论。再次澄清一下俺的需求（虽然俺知道后面的讨论已经可以独
: 立于俺的问题来学习了），基本就是这样的：
: -------------------------------------------
: 发信人: brainless (n/a), 信区: Programming
: 标 题: Re: 求推荐database的软件 (转载)
: 发信站: BBS 未名空间站 (Sun Sep 22 21:47:00 2013, 美东)
: 我觉得他就是在做一个实验室里用的东西，访问量不会大
: 不需要view之类，一个表就够了
: 就是一台机器做db host
: 其它采集的机器装个mysql client，简单一两条statement更新下数据
|
z****e
发帖数: 54598 | 47 他说的是这只
发信人: rodeo (rodeo), 信区: Programming
标 题: Re: 求推荐database的软件 (转载)
发信站: BBS 未名空间站 (Sun Sep 22 21:58:18 2013, 美东)
用MS的SQL Server 2012。一个SSIS package搞定，前台用.Net写个Web界面作数据分析
和报告也很容易
【在 b*******s 的大作中提到】
: mysql是oracle的
|
b*******s
发帖数: 5216 | 48 哦？说说看为什么？
【在 z****e 的大作中提到】
: 火车票那种最适合的应该是主机，而不是什么分布式
: 飞机票全球就是清一色主机
|
z****e
发帖数: 54598 | 49 你研究一下分布式的transaction就知道了
理论上无解
【在 b*******s 的大作中提到】
: 哦？说说看为什么？
|
b*******s
发帖数: 5216 | 50 给两个关键性的结论吧
谢谢
【在 z****e 的大作中提到】
: 你研究一下分布式的transaction就知道了
: 理论上无解
|
|
|
z****e
发帖数: 54598 | 51 1)分布式对transaction无理论上的绝对解
目前唯一能做的就是采用两段式的事务来搞定
第一次向全部nodes发送start transaction命令
然后收集到全部反馈之后，再发送end transaction命令
然后assume全部nodes都会正确执行这后一条命令
这能解决大部分问题，但是不排除某一种特殊情况出现
后面那个assumption可能不成立，分布式经常出各种同信问题
所以不能保证一致性，从cap理论上看
db的主要问题也主要出现在partition tolerance上
两段式事务在一些集中的环境，比如同一个机房
保证所有机器之间的连接不被打断的时候
还是可以的，这个可以看作是一种比较弱的分布式系统
2)cap牺牲什么c还是a还是p，都有特定的方案
其中牺牲p最简单，最直观，不scale out了
就只scale up，最巅峰状态就是各种主机和hpc了
其次是牺牲c，那这个其实是最分布式的一种形态，一个主题，各自表述
当然客户最后得到的是什么结果，自己去判断
最典型的是搜索引擎，你不能保证你得到的结果一定是你想要的
你自己去判断，同一个东西在不同的地方很有可能是不同的
其中不少是错的不奇怪
最后是牺牲a，那这个是voting system
master node对所有结点发出任务，最后收集到一定程度的同向反馈后
就取这个结果为最终结果，比如master node向slave nodes发送100个request
问一个简单的yes/no问题，只要收集到51个回答是yes或者no，就返回
当然有50－50的情况，这种情况master node要自己决定，返回是必需的
这样不是所有nodes都必需应答，这样a就被牺牲掉，但是每一次同样问题
回答都是一致的，这就保证了c，但是牺牲了a
3)联系到火车票问题，你能牺牲哪一个？
a和c显然都不能被牺牲，否则必然引发混乱
而且涉及到钱的交易，transaction几乎是必需的
而怎么partition几乎都会在transaction上出问题
所以最好不要上分布式的系统，上主机
就算要做分布式，也只能做弱分布式系统，比如自己建一个庞大的数据中心
然后在里面放五六台机器，保证这些机器之间的连接不被打断
但是这样做其实还不如做主机，从性价比上说，两个其实差不太多
【在 b*******s 的大作中提到】
: 给两个关键性的结论吧
: 谢谢
|
p*****2
发帖数: 21240 | 52
刚才稍微看了一下。感觉LZ的情况mongo应该还是更容易一些。
【在 z****e 的大作中提到】
: couchdb最适合的一个场景就是内存比较少的地方
: http://stackoverflow.com/questions/10314272/couchdb-vs-mongodb-
: 实际上疯狂依赖内存的db，除了mongodb，其它nosql几乎没有这样设计
: mongodb真是nosql的一个奇芭
|
p*****2
发帖数: 21240 | 53
为什么NoSQL是瞎折腾呢？我感觉比sql好用呀
【在 g*****g 的大作中提到】
: 这么点数据，上啥NoSQL，都是瞎折腾。MySQL/ProgreSQL就很好。
|
s***o
发帖数: 2191 | 54 很好奇你老板为啥希望用nosql
该不会是因为这个词fancy and cool吧？
我比较同意好虫说的。
【在 f***c 的大作中提到】
: 首先非常感谢各位的讨论。再次澄清一下俺的需求（虽然俺知道后面的讨论已经可以独
: 立于俺的问题来学习了），基本就是这样的：
: -------------------------------------------
: 发信人: brainless (n/a), 信区: Programming
: 标 题: Re: 求推荐database的软件 (转载)
: 发信站: BBS 未名空间站 (Sun Sep 22 21:47:00 2013, 美东)
: 我觉得他就是在做一个实验室里用的东西，访问量不会大
: 不需要view之类，一个表就够了
: 就是一台机器做db host
: 其它采集的机器装个mysql client，简单一两条statement更新下数据
|
p*****2
发帖数: 21240 | 55
对比nosql，sql在LZ的情况有啥优势呢？
【在 s***o 的大作中提到】
: 很好奇你老板为啥希望用nosql
: 该不会是因为这个词fancy and cool吧？
: 我比较同意好虫说的。
|
z****e
发帖数: 54598 | 56 couchdb好用，简单
但是不能保证其它所有的nosql都简单
比如mongodb，配置就很折腾
而且做了一半半，最大的好处就是保留了一些sql的语法
但如果这样，还不如去用db
【在 p*****2 的大作中提到】
:
: 对比nosql，sql在LZ的情况有啥优势呢？
|
p*****2
发帖数: 21240 | 57
mongo配置为什么折腾呀？
【在 z****e 的大作中提到】
: couchdb好用，简单
: 但是不能保证其它所有的nosql都简单
: 比如mongodb，配置就很折腾
: 而且做了一半半，最大的好处就是保留了一些sql的语法
: 但如果这样，还不如去用db
|
g*****g
发帖数: 34805 | 58 NoSQL意思是Not only SQL，通常是RDMBS不够用，特别是HA要求高的场合用来补充用的。
否则RDBMS从transaction support, queries, tools, stability各方面都是秒杀NoSQL。
当数据量那么小，完全没有HA的需求的时候，非去用NoSQL就是给自己找麻烦。
【在 p*****2 的大作中提到】
:
: mongo配置为什么折腾呀？
|
z****e
发帖数: 54598 | 59 最常见的，先把index全部读入内存
一旦内存不够用，怎么转就折腾了
【在 p*****2 的大作中提到】
:
: mongo配置为什么折腾呀？
|
b*******s
发帖数: 5216 | 60 嗯，谢谢
【在 z****e 的大作中提到】
: 1)分布式对transaction无理论上的绝对解
: 目前唯一能做的就是采用两段式的事务来搞定
: 第一次向全部nodes发送start transaction命令
: 然后收集到全部反馈之后，再发送end transaction命令
: 然后assume全部nodes都会正确执行这后一条命令
: 这能解决大部分问题，但是不排除某一种特殊情况出现
: 后面那个assumption可能不成立，分布式经常出各种同信问题
: 所以不能保证一致性，从cap理论上看
: db的主要问题也主要出现在partition tolerance上
: 两段式事务在一些集中的环境，比如同一个机房
|
|
|
z****e
发帖数: 54598 | 61 这些tool对于couchdb来说都不是必需的
couchdb一分钟就可以上手
的。
NoSQL。
【在 g*****g 的大作中提到】
: NoSQL意思是Not only SQL，通常是RDMBS不够用，特别是HA要求高的场合用来补充用的。
: 否则RDBMS从transaction support, queries, tools, stability各方面都是秒杀NoSQL。
: 当数据量那么小，完全没有HA的需求的时候，非去用NoSQL就是给自己找麻烦。
|
p*****2
发帖数: 21240 | 62
这个情况应该如何配置？
【在 z****e 的大作中提到】
: 最常见的，先把index全部读入内存
: 一旦内存不够用，怎么转就折腾了
|
p*****2
发帖数: 21240 | 63
的。
NoSQL。
nosql能解决的问题，用sql不也是折腾吗？再说了，现在很多情况nosql是可以replace
sql的。不然nosql怎么这么火呢。
【在 g*****g 的大作中提到】
: NoSQL意思是Not only SQL，通常是RDMBS不够用，特别是HA要求高的场合用来补充用的。
: 否则RDBMS从transaction support, queries, tools, stability各方面都是秒杀NoSQL。
: 当数据量那么小，完全没有HA的需求的时候，非去用NoSQL就是给自己找麻烦。
|
z****e
发帖数: 54598 | 64 我也不记得了，据说有
但是如果直接操作内存的话
我自己写的类，也慢不了多少，而且怎么写还很自由
【在 p*****2 的大作中提到】
:
: 的。
: NoSQL。
: nosql能解决的问题，用sql不也是折腾吗？再说了，现在很多情况nosql是可以replace
: sql的。不然nosql怎么这么火呢。
|
z****e
发帖数: 54598 | 65 couchdb不折腾，你们慢慢折腾
replace
【在 p*****2 的大作中提到】
:
: 的。
: NoSQL。
: nosql能解决的问题，用sql不也是折腾吗？再说了，现在很多情况nosql是可以replace
: sql的。不然nosql怎么这么火呢。
|
g*****g
发帖数: 34805 | 66 这不是扯的吗。无论mongodb，还是counchdb，让你做个简单的join，你就知道NoSQL为
啥麻烦了。
【在 z****e 的大作中提到】
: 这些tool对于couchdb来说都不是必需的
: couchdb一分钟就可以上手
:
: 的。
: NoSQL。
|
p*****2
发帖数: 21240 | 67
向LZ的情况，内存应该不是什么问题。自己写的不能persistent。
【在 z****e 的大作中提到】
: 我也不记得了，据说有
: 但是如果直接操作内存的话
: 我自己写的类，也慢不了多少，而且怎么写还很自由
|
p*****2
发帖数: 21240 | 68
couchdb有些特性挺好的。
【在 z****e 的大作中提到】
: couchdb不折腾，你们慢慢折腾
:
: replace
|
p*****2
发帖数: 21240 | 69
nosql基本都没有join吧。但是很多应用也不需要join吧？而且mongo可以内嵌，可以解
决一部分join的需求。
【在 g*****g 的大作中提到】
: 这不是扯的吗。无论mongodb，还是counchdb，让你做个简单的join，你就知道NoSQL为
: 啥麻烦了。
|
z****e
发帖数: 54598 | 70 把join压给persistence去做就是折腾
是我的话，情愿先取出来，留在一个list里面
然后挨个遍历list，再做二次查询
我不在乎io次数多还是少，你们主张用db的才喜欢用join
mongodb和mysql有很大重叠
MongoDB (2.2)
For example: For most things that you would do with MySQL or PostgreSQL, but
having predefined columns really holds you back.
【在 g*****g 的大作中提到】
: 这不是扯的吗。无论mongodb，还是counchdb，让你做个简单的join，你就知道NoSQL为
: 啥麻烦了。
|
|
|
g*****g
发帖数: 34805 | 71 NoSQL火是因为HA的需要，否则连个简单的Join都费老劲了。
不用RDMBS是因为RDMBS性能不够好，HA不够好，而不是因为RDMBS功能弱。
在没性能，HA方面要求时，就是瞎折腾。
replace
【在 p*****2 的大作中提到】
:
: nosql基本都没有join吧。但是很多应用也不需要join吧？而且mongo可以内嵌，可以解
: 决一部分join的需求。
|
z****e
发帖数: 54598 | 72 persistence的话我放couchdb，怎么操作，我用高级语言做
不依赖db
【在 p*****2 的大作中提到】
:
: nosql基本都没有join吧。但是很多应用也不需要join吧？而且mongo可以内嵌，可以解
: 决一部分join的需求。
|
p*****2
发帖数: 21240 | 73
sql的migration也是很恶心的
【在 g*****g 的大作中提到】
: NoSQL火是因为HA的需要，否则连个简单的Join都费老劲了。
: 不用RDMBS是因为RDMBS性能不够好，HA不够好，而不是因为RDMBS功能弱。
: 在没性能，HA方面要求时，就是瞎折腾。
:
: replace
|
g*****g
发帖数: 34805 | 74 先不提性能问题，就你说的这个，难道实现不是比一个DB join复杂10倍？
没性能需求的时候图啥，没事把代码写复杂有必要吗。
but
【在 z****e 的大作中提到】
: 把join压给persistence去做就是折腾
: 是我的话，情愿先取出来，留在一个list里面
: 然后挨个遍历list，再做二次查询
: 我不在乎io次数多还是少，你们主张用db的才喜欢用join
: mongodb和mysql有很大重叠
: MongoDB (2.2)
: For example: For most things that you would do with MySQL or PostgreSQL, but
: having predefined columns really holds you back.
|
p*****2
发帖数: 21240 | 75
你不经常说不要自己造轮子吗？
【在 z****e 的大作中提到】
: persistence的话我放couchdb，怎么操作，我用高级语言做
: 不依赖db
|
z****e
发帖数: 54598 | 76 哪里会复杂10倍
一个简单的循环就搞定了
而且还是高级语言搞定的
比如sql写的容易多了
会python或者会java的，看一眼就知道在做什么
sql写的才难懂，你看store proc.里面一堆乱七八糟的东西
【在 g*****g 的大作中提到】
: 先不提性能问题，就你说的这个，难道实现不是比一个DB join复杂10倍？
: 没性能需求的时候图啥，没事把代码写复杂有必要吗。
:
: but
|
p*****2
发帖数: 21240 | 77
我觉得图的是灵活吧。column可以随便改。
【在 g*****g 的大作中提到】
: 先不提性能问题，就你说的这个，难道实现不是比一个DB join复杂10倍？
: 没性能需求的时候图啥，没事把代码写复杂有必要吗。
:
: but
|
z****e
发帖数: 54598 | 78 trade off啊
简单上手后面还回去点很正常
不能诸事都完美
【在 p*****2 的大作中提到】
:
: 我觉得图的是灵活吧。column可以随便改。
|
p*****2
发帖数: 21240 | 79
不过你做个mongo出来也不容易呀。
【在 z****e 的大作中提到】
: trade off啊
: 简单上手后面还回去点很正常
: 不能诸事都完美
|
g*****g
发帖数: 34805 | 80 一个join跟stored proc是两码事。join是大量用的，但凡俩table有关系就能用到，
哪怕你用JPA也无非是自动生成，
【在 z****e 的大作中提到】
: 哪里会复杂10倍
: 一个简单的循环就搞定了
: 而且还是高级语言搞定的
: 比如sql写的容易多了
: 会python或者会java的，看一眼就知道在做什么
: sql写的才难懂，你看store proc.里面一堆乱七八糟的东西
|
|
|
z****e
发帖数: 54598 | 81 如果有transaction之类需求时候
我用db，不用mongo
【在 p*****2 的大作中提到】
:
: 不过你做个mongo出来也不容易呀。
|
z****e
发帖数: 54598 | 82 你看楼主那种，像是大量用到的么？
他采集的是文件信息
【在 g*****g 的大作中提到】
: 一个join跟stored proc是两码事。join是大量用的，但凡俩table有关系就能用到，
: 哪怕你用JPA也无非是自动生成，
|
p*****2
发帖数: 21240 | 83
那当然了。
【在 z****e 的大作中提到】
: 如果有transaction之类需求时候
: 我用db，不用mongo
|
g*****g
发帖数: 34805 | 84 column可以随便改是啥好处？纯粹是为了HA，你看LZ那需求，有99.9%的availability
要求吗？
没有的话，改完了重启一下应用屁大的事。
【在 p*****2 的大作中提到】
:
: 那当然了。
|
z****e
发帖数: 54598 | 85 上次它们讨论不是说store proc.主要是用join么？
减少io次数，要不然就不用store proc.了
【在 g*****g 的大作中提到】
: 一个join跟stored proc是两码事。join是大量用的，但凡俩table有关系就能用到，
: 哪怕你用JPA也无非是自动生成，
|
p*****2
发帖数: 21240 | 86
availability
关键是nosql还是比sql要容易方便呀。机器也不需要重启，干吗一定要用sql呢？
【在 g*****g 的大作中提到】
: column可以随便改是啥好处？纯粹是为了HA，你看LZ那需求，有99.9%的availability
: 要求吗？
: 没有的话，改完了重启一下应用屁大的事。
|
z****e
发帖数: 54598 | 87 mongodb未必比mysql简单
couchdb可比你们说的都简单
【在 p*****2 的大作中提到】
:
: availability
: 关键是nosql还是比sql要容易方便呀。机器也不需要重启，干吗一定要用sql呢？
|
g*****g
发帖数: 34805 | 88 我再说一遍，NoSQL是确定RDBMS不够用的时候才用的，而不是反过来。
楼主那点东西，RDBMS哪点不够用？
【在 z****e 的大作中提到】
: 你看楼主那种，像是大量用到的么？
: 他采集的是文件信息
|
z****e
发帖数: 54598 | 89 当然够用，但是我觉得couchdb也足够他用了
couchdb可不是rdbms那么高端的东西
就是一个简单的rest+json，没啥东西
【在 g*****g 的大作中提到】
: 我再说一遍，NoSQL是确定RDBMS不够用的时候才用的，而不是反过来。
: 楼主那点东西，RDBMS哪点不够用？
|
g*****g
发帖数: 34805 | 90 我老懒得继续费劲，啥东西都是实践出来的经验。NoSQL是迫不得已才用的，不是因为
比RDBMS好用。
信不信由你吧。
【在 p*****2 的大作中提到】
:
: availability
: 关键是nosql还是比sql要容易方便呀。机器也不需要重启，干吗一定要用sql呢？
|
|
|
p*****2
发帖数: 21240 | 91
你这个statement是从哪里来的？能有个reference吗？这些需要研究一下。
【在 g*****g 的大作中提到】
: 我再说一遍，NoSQL是确定RDBMS不够用的时候才用的，而不是反过来。
: 楼主那点东西，RDBMS哪点不够用？
|
p*****2
发帖数: 21240 | 92
也要看use case吧？
【在 g*****g 的大作中提到】
: 我老懒得继续费劲，啥东西都是实践出来的经验。NoSQL是迫不得已才用的，不是因为
: 比RDBMS好用。
: 信不信由你吧。
|
g*****g
发帖数: 34805 | 93 这个是我老用了三年NoSQL DB的结论。
【在 p*****2 的大作中提到】
:
: 也要看use case吧？
|
p*****2
发帖数: 21240 | 94
couch没用过，但是感觉用起来也未必简单。但是LZ的情况应该还挺适合couch的。
mongo和sql我是觉得sql要难用很多，能不用我就不用。
【在 z****e 的大作中提到】
: mongodb未必比mysql简单
: couchdb可比你们说的都简单
|
g*****g
发帖数: 34805 | 95 LZ的Use case.
【在 p*****2 的大作中提到】
:
: couch没用过，但是感觉用起来也未必简单。但是LZ的情况应该还挺适合couch的。
: mongo和sql我是觉得sql要难用很多，能不用我就不用。
|
b*******s
发帖数: 5216 | 96 火车订票系统，我觉得主要的问题都是流程上的，技术上倒不是最麻烦的
比如预售期短,如果能预售三个月，问题就会少很多
那个火车票系统其实可以结合分布式和主机
主要是从需求来看，首先火车运营是能按照线路和车次进行拆分的
可以减少同步
其次主要的负载是和用户使用习惯有关的
用户多数事前不做homework，都是上去了不停的翻，比较，查找
但是这样就提供了一种机会，不牵涉钱的前面的这些翻找
是可以不要求严格的同步
到后面需要付钱了再走transaction
单纯二三十亿个会话，在两三周内发生，不算无法控制
mango我觉得还是比较合适的
【在 z****e 的大作中提到】
: 1)分布式对transaction无理论上的绝对解
: 目前唯一能做的就是采用两段式的事务来搞定
: 第一次向全部nodes发送start transaction命令
: 然后收集到全部反馈之后，再发送end transaction命令
: 然后assume全部nodes都会正确执行这后一条命令
: 这能解决大部分问题，但是不排除某一种特殊情况出现
: 后面那个assumption可能不成立，分布式经常出各种同信问题
: 所以不能保证一致性，从cap理论上看
: db的主要问题也主要出现在partition tolerance上
: 两段式事务在一些集中的环境，比如同一个机房
|
z****e
发帖数: 54598 | 97 我上手mongodb也就是五分钟
我相信你最多十分钟搞定
【在 p*****2 的大作中提到】
:
: couch没用过，但是感觉用起来也未必简单。但是LZ的情况应该还挺适合couch的。
: mongo和sql我是觉得sql要难用很多，能不用我就不用。
|
z****e
发帖数: 54598 | 98 cassandra，hbase还有dynamo这些重量级的东西的确比一般的mysql什么要复杂
而且大有取代之势
但是说couchdb这些要取代rdbms，有些太抬举couch了
【在 g*****g 的大作中提到】
: 这个是我老用了三年NoSQL DB的结论。
|
p*****2
发帖数: 21240 | 99
我已经用了一段时间了，也算是比较熟一些了。大概的情况还基本都知道。
【在 z****e 的大作中提到】
: 我上手mongodb也就是五分钟
: 我相信你最多十分钟搞定
|
w**z
发帖数: 8232 | 100 量大,nosql 的优势就显示出来了，mysql shard, read slave is a real pain. lz
的情况MySQL 足以。 我们用C *的原因就是数据量大，alter table 没法run. If you
want to go prod with nosql, you better know what you are doing... Running
on your laptop is totally different from running with hundreds of nodes.
【在 p*****2 的大作中提到】
:
: 我已经用了一段时间了，也算是比较熟一些了。大概的情况还基本都知道。
|
|
|
p*****2
发帖数: 21240 | 101
you
Running
nosql没有确定的定义吧？至少大家认为nosql是分三种吧？你说的cassandra只是其中
的一种吧？另外两种自有各自的应用场景。
【在 w**z 的大作中提到】
: 量大,nosql 的优势就显示出来了，mysql shard, read slave is a real pain. lz
: 的情况MySQL 足以。 我们用C *的原因就是数据量大，alter table 没法run. If you
: want to go prod with nosql, you better know what you are doing... Running
: on your laptop is totally different from running with hundreds of nodes.
|
z****e
发帖数: 54598 | 102 前面写错了
应该是我上手couchdb也就是5分钟的事
你上手也就是10分钟最多了
【在 p*****2 的大作中提到】
:
: you
: Running
: nosql没有确定的定义吧？至少大家认为nosql是分三种吧？你说的cassandra只是其中
: 的一种吧？另外两种自有各自的应用场景。
|
z****e
发帖数: 54598 | 103 2
其中一种是rdbms
【在 p*****2 的大作中提到】
:
: you
: Running
: nosql没有确定的定义吧？至少大家认为nosql是分三种吧？你说的cassandra只是其中
: 的一种吧？另外两种自有各自的应用场景。
|
p*****2
发帖数: 21240 | 104
couchdb我以前稍微看过一下，上手确实容易。因为用到的都是大家已经知道的技术，
所以有相关背景的话，真是几分钟就可以用了。这点确实比mongo要上手快。
【在 z****e 的大作中提到】
: 前面写错了
: 应该是我上手couchdb也就是5分钟的事
: 你上手也就是10分钟最多了
|
z****e
发帖数: 54598 | 105 选票订票和金钱交易都是transaction的一部分
金钱交易失败，订票也要回滚
【在 b*******s 的大作中提到】
: 火车订票系统，我觉得主要的问题都是流程上的，技术上倒不是最麻烦的
: 比如预售期短,如果能预售三个月，问题就会少很多
: 那个火车票系统其实可以结合分布式和主机
: 主要是从需求来看，首先火车运营是能按照线路和车次进行拆分的
: 可以减少同步
: 其次主要的负载是和用户使用习惯有关的
: 用户多数事前不做homework，都是上去了不停的翻，比较，查找
: 但是这样就提供了一种机会，不牵涉钱的前面的这些翻找
: 是可以不要求严格的同步
: 到后面需要付钱了再走transaction
|
z****e
发帖数: 54598 | 106 尤其适合楼主这样会js和py的
【在 p*****2 的大作中提到】
:
: couchdb我以前稍微看过一下，上手确实容易。因为用到的都是大家已经知道的技术，
: 所以有相关背景的话，真是几分钟就可以用了。这点确实比mongo要上手快。
|
p*****2
发帖数: 21240 | 107
我觉得是适合的，就是不清楚performance，因为用的是rest和json，理论上性能不如
mongo。但是LZ的需求满足应该没啥问题了。到时候LZ汇报一下情况吧。
【在 z****e 的大作中提到】
: 尤其适合楼主这样会js和py的
|
g*****g
发帖数: 34805 | 108 NoSQL的一些feature固然好，但吃螃蟹都是有代价的。举个最实在的，谁来维护这个数
据库？
如果是Oracle, MySQL，一般的公司，都有专门的DBA或者System admin，至少升级这些
破事不用你管了。就算没有，基本上常见的问题都被讨论过了，自己google也能解决。
到了NoSQL，一旦上了产品，出了问题，就得自己解决，基本上只有自己读代码上
maillist问两条路。所有对数据库的监控啥的，可能没有成熟的产品，也得摸着石头过
河。
如果是自己的Pet project，咋写都行。对于没有HA和性能的要求又要上这些不成熟的
数据库，风险是很大的，你可能发现一半多的时间都在维护数据库，而不是开发。 |
w**z
发帖数: 8232 | 109 exactly what happened to me. 好不容易才把C * 的维护交给techop. 人也不愿意接
。你看一下maillist 上的关于维护的问题，就知道了。 我有一次周六早上被从被窝里
叫起来，C * ran out of heap memory because of the stupid repair. .. it is no
fun.
【在 g*****g 的大作中提到】
: NoSQL的一些feature固然好，但吃螃蟹都是有代价的。举个最实在的，谁来维护这个数
: 据库？
: 如果是Oracle, MySQL，一般的公司，都有专门的DBA或者System admin，至少升级这些
: 破事不用你管了。就算没有，基本上常见的问题都被讨论过了，自己google也能解决。
: 到了NoSQL，一旦上了产品，出了问题，就得自己解决，基本上只有自己读代码上
: maillist问两条路。所有对数据库的监控啥的，可能没有成熟的产品，也得摸着石头过
: 河。
: 如果是自己的Pet project，咋写都行。对于没有HA和性能的要求又要上这些不成熟的
: 数据库，风险是很大的，你可能发现一半多的时间都在维护数据库，而不是开发。
|
w***g
发帖数: 5958 | 110 如果是表格数据的话mysql或者postgresql就可以了.
【在 f***c 的大作中提到】
: 不大，单个文件<1M.。
: 每天有30多个文件。实在说不上是大数据。
: 本来跟老板讲些个script，每天ftp上传，然后用python parse，生成csv，用excel的
: spread sheet处理。
: 但是老板说为了更正式些，要建立database。
: 谢谢。
|
|
|
z****e
发帖数: 54598 | 111 楼主这种可能雇佣dba么？
再说，你们都不雇dba了
现在全世界挨踢公司都在学习你们的模式
以后没有dba了，公司会用sql好的developer来当dba
那到时候还不是得自己去倒腾
对于developer来说，nosql大部分产品其实比db更有亲切感
一半时间在维护，剩下时间开发，这个对于大多数现有系统来说应该是常态
不仅仅是persistence
【在 g*****g 的大作中提到】
: NoSQL的一些feature固然好，但吃螃蟹都是有代价的。举个最实在的，谁来维护这个数
: 据库？
: 如果是Oracle, MySQL，一般的公司，都有专门的DBA或者System admin，至少升级这些
: 破事不用你管了。就算没有，基本上常见的问题都被讨论过了，自己google也能解决。
: 到了NoSQL，一旦上了产品，出了问题，就得自己解决，基本上只有自己读代码上
: maillist问两条路。所有对数据库的监控啥的，可能没有成熟的产品，也得摸着石头过
: 河。
: 如果是自己的Pet project，咋写都行。对于没有HA和性能的要求又要上这些不成熟的
: 数据库，风险是很大的，你可能发现一半多的时间都在维护数据库，而不是开发。
|
