m****s
发帖数: 18160 | 1 【 以下文字转载自 Database 讨论区 】
发信人: jelty (TT is refreshing), 信区: Database
标 题: DBA opening in Bay area and Boston
发信站: BBS 未名空间站 (Thu Apr 10 01:17:40 2014, 美东)
you can send me your resume to j*******[email protected] or apply directly through
our company website
About Lattice
Lattice is an early innovator in one of the hottest areas of the marketing
technology market: predictive applications. We bring every relevant buying
signal into the industry’s most comprehensive cloud-based suite of business
appli... 阅读全帖 |
|
j****g
发帖数: 17 | 2 职位期望Master 毕业5年，PhD毕业3年以及以上，具体情况可以case by case！
资深岗位 关键词
分布式存储研发专家 块存储、冷数据存储、数据库存储，集群存储
虚拟网络研发专家 Linux下的网络、SDN、Overlay网络设计
云业务系统运维专家 虚拟化、云计算容器，微服务（mangodb/redis/cassandra）
nosql存储
网络运维专家 机房网络、VPC、负载均衡、trouble shooting
资深研发架构师 网络安全、存储系统开发、虚拟化技术、移动应用等技
术经验优先
资深数据库专家 Mysql/MongoDB/PostgreSql/InnoDB/NoSql/DynamoDB/
AWS-S3
资深分布式存储专家 MangoDB/Redis/Cassandra等nosql存储
资深大数据工程专家 Spark/Flink/Hadoop/Yarn/Hive/Storm、开源、实时... 阅读全帖 |
|
发帖数: 1 | 3 以下为重要紧急职位期望Master 毕业5年，PhD毕业3年以及以上，具体情况可以case
by case！
资深岗位 关键词
分布式存储研发专家 块存储、冷数据存储、数据库存储，集群存储
虚拟网络研发专家 Linux下的网络、SDN、Overlay网络设计
云业务系统运维专家 虚拟化、云计算容器，微服务（mangodb/redis/cassandra）
nosql存储
网络运维专家 机房网络、VPC、负载均衡、trouble shooting
资深研发架构师 网络安全、存储系统开发、虚拟化技术、移动应用等技
术经验优先
资深数据库专家 Mysql/MongoDB/PostgreSql/InnoDB/NoSql/DynamoDB/
AWS-S3
资深分布式存储专家 MangoDB/Redis/Cassandra等nosql存储
资深大数据工程专家 Spark/Flink/Hadoop/Yarn/Hive/Stor... 阅读全帖 |
|
g*********9
发帖数: 1285 | 4 金玉良言。去年一帮子青蛙在文科生带领下抄女大，已成股版笑话
：数据库现在确实大数据上都要用上NoSQL DB，MongoDB是NoSQL，但在各个公司用到它
有多广泛就要打个疑问。而且它被替代的可能性不是不大. open source based NoSQL
：databases太多了, 像kv based的，gragh based, document based等等. Mongo db是 |
|
g*********9
发帖数: 1285 | 5 金玉良言。去年一帮子青蛙在文科生带领下抄女大，已成股版笑话
：数据库现在确实大数据上都要用上NoSQL DB，MongoDB是NoSQL，但在各个公司用到它
有多广泛就要打个疑问。而且它被替代的可能性不是不大. open source based NoSQL
：databases太多了, 像kv based的，gragh based, document based等等. Mongo db是 |
|
c*****8
发帖数: 23 | 6 有兴趣的同学请发站内信，帮忙介绍的同学如果内推成功，可平分奖金：）
Sr Software Engineer - Data Science Pipeline - Big Data, Java, Python
Job LocationsUS-IL-Chicago
Qualifications
A BS or MS in Computer Science or related field
5+ years of programming experience Java, Python, and Java Script.
3+ years of working experience with AWS services (EC2, SNS, SQS, S3, EMR,
Data Pipeline, VPC and etc.)
Development experience of Web Services (RESTful, SOAP)
Development experience with web application frameworks - Spring /Spring Boot
/Angu... 阅读全帖 |
|
z****e
发帖数: 54598 | 7 谁不宰？
你以为m$不宰？
薪水高没什么奇怪的
主机的architect的薪水更高
有些东西就是越稀少工资越高
但是平均而言，工作机会数量就是另外一回事
你要做得好，搞数学薪水也能很高
nosql当然不是db，当然有些人硬要说是db
那这个其实只是概念的不同罢了
nosql的dba到现在目测还没有出现
每一个nosql db产品都不同，怎么个a法？
大多数时候就是开发做，所以开发要的人多 |
|
z****e
发帖数: 54598 | 8 nosql要的其实不是db architect
应该说是architect
拘束在db上就显然太小了
architect从前到后都得做
db开发经验其实是基本功
nosql是plus，但是现在web大发展
以后nosql变成基本功，db成plus了也不一定
将来的事，谁说得清楚呢
另外稍微大一点的公司都有自己的cio，cio下面一堆挨踢的
所以会挨踢的人还是挺多的，每年大学都在毕业cs的毕业生
并不少，完全可以应付各个中小公司的挨踢
而这些挨踢才是开源使用的主力军，netflix就是典型
netflix就不是什么挨踢企业，当然是web企业
但是主业是娱乐，人家用开源用得如火如荼
类似的，银行里面很多开发人员，也都不靠挨踢公司过活
所以牛人把开源做得越好，只会push更多的人到其它行业去做挨踢
而不会减少挨踢工作机会，总量会上升
但是对于像微软这种公司来说，未必是好事
因为开源会的人多了，有什么理由去用收费的东西呢？
类似的，fb什么其实也不能说是挨踢企业，fb搞社交的
google是卖广告的，从某种意义上说，传统的挨踢正在凋零
不跟其它业务结合，挨踢本身没有太大意义 |
|
z****e
发帖数: 54598 | 9 nosql当然不是包治百病
db对于结构化存储要求比较高的部分还是需要的
但是nosql自身也在学习
现在nosql开始逐步添加transaction功能
这才是真正威胁db生存的决定
你说对不对？ |
|
z****e
发帖数: 54598 | 10 谁不宰？
你以为m$不宰？
薪水高没什么奇怪的
主机的architect的薪水更高
有些东西就是越稀少工资越高
但是平均而言，工作机会数量就是另外一回事
你要做得好，搞数学薪水也能很高
nosql当然不是db，当然有些人硬要说是db
那这个其实只是概念的不同罢了
nosql的dba到现在目测还没有出现
每一个nosql db产品都不同，怎么个a法？
大多数时候就是开发做，所以开发要的人多 |
|
z****e
发帖数: 54598 | 11 nosql要的其实不是db architect
应该说是architect
拘束在db上就显然太小了
architect从前到后都得做
db开发经验其实是基本功
nosql是plus，但是现在web大发展
以后nosql变成基本功，db成plus了也不一定
将来的事，谁说得清楚呢
另外稍微大一点的公司都有自己的cio，cio下面一堆挨踢的
所以会挨踢的人还是挺多的，每年大学都在毕业cs的毕业生
并不少，完全可以应付各个中小公司的挨踢
而这些挨踢才是开源使用的主力军，netflix就是典型
netflix就不是什么挨踢企业，当然是web企业
但是主业是娱乐，人家用开源用得如火如荼
类似的，银行里面很多开发人员，也都不靠挨踢公司过活
所以牛人把开源做得越好，只会push更多的人到其它行业去做挨踢
而不会减少挨踢工作机会，总量会上升
但是对于像微软这种公司来说，未必是好事
因为开源会的人多了，有什么理由去用收费的东西呢？
类似的，fb什么其实也不能说是挨踢企业，fb搞社交的
google是卖广告的，从某种意义上说，传统的挨踢正在凋零
不跟其它业务结合，挨踢本身没有太大意义 |
|
z****e
发帖数: 54598 | 12 nosql当然不是包治百病
db对于结构化存储要求比较高的部分还是需要的
但是nosql自身也在学习
现在nosql开始逐步添加transaction功能
这才是真正威胁db生存的决定
你说对不对？ |
|
n******1
发帖数: 3756 | 13 我个人感觉也是差不多，主要想了解一下这几年有些什么突破，可以成为一个爆发点
其实BI也算不上新东西了，喊了很多年，但是一直也没有很成功的样子
nosql倒是业界需求驱动出来的，不过都在google,facebook这些怪兽级应用上，企业内
部有结构化数据，也有各类非结构化数据，我个人感觉其实nosql和sql的结合需求还是
强大的，但是问题是etl这一步特别难，因为非结构数据本身就是非结构的，即使nosql
去掉R，仍然需要有一定的结构，所以又回到怎么样可以etl有意义的数据问题上 |
|
s**********o
发帖数: 14359 | 14 还想着NOSQL啊，人NOSQL是因为是BLOG,VIDEO和JPEG，
你没有这些搞什么NOSQL啊，就是因为当初的SOLUTION
是失败的，所以才搞不了YEARLY的，还抱着那个PARSE
人为的OVERHEAD不放。 |
|
f*******h
发帖数: 1269 | 15 Big data is another bubble.
Among these, MapReduce is one driving technology for data analytics, and
NoSQL is another one for scalable databases.
For MapReduce, read two books:
Hadoop Definitive Guide
MapReduce Design Patterns.
For NoSQL:
Book: NoSQL Distilled.
http://www.christof-strauch.de/nosqldbs.pdf |
|
o**1
发帖数: 6383 | 16 google app engine 用的是bigtable, 不是传统的 relational 数据库，属于NoSQL.
Amazon的云计算用的是 SimpleDB 也属于NoSql的一种。
NoSql 数据库应该会逐渐流行起来，老的 Relational database 也该退休了，ORM 问
题搞的程序员很不爽。 |
|
B*****g
发帖数: 34098 | 17 你说的这都是relational database的缺点，和plsql自身没关系。对大多数公司来说一
时半会都不会用NoSQL数据库，而且你自己也说过NoSQL数据库的缺点。另外也不用老把
钱拿出来说，用oracle的公司有的是钱，没钱就去用mysql。坑爹美国政府100+个table
的数据库也要用oracle。
你搞个NoSql的讲座吧，很多人其实还不是很清楚咋回事。 |
|
t***a
发帖数: 416 | 18 是可以让hibernate来mapping nosql的。。。。这和mapping到关系型数据库，其实本
质上也没啥不同。。。。。没transaction是nosql自己的问题，就像以前innodb没
foreign key一样
当然用hibernate连nosql这事好不好，需要讨论，但要真不想重写Dao, 也是可以忍的 |
|
z****e
发帖数: 54598 | 19 只能说你们的developer比较懒
这种join其实是很老旧的设计
应该把关键数据剥离出来，单独用transaction保证其数据安全
transaction可以用container来做
也可以自己用jdbc设置start&end point
或者交给hibernate去管理
然后其它的非关键数据，全部用nosql来搞定
真正一个公司最关键的数据无非两个，一个账户信息，还有一个交易信息
这两个需要transaction，其它的其实无关紧要，什么crm都应该上nosql
就是银行也可以用nosql，更何况其它商业公司 |
|
r*****s
发帖数: 985 | 20 I meant I was not convinced so.
sigh ...
谦虚一点都不行
拿个Beberley+MIT的Theroem就能prove NoSQL了？
你有点被netflix洗脑了，
抱歉，
说的有点难听。
这个HA, Scalability,ACID本来就是个大标题,
就像你说的，
RDB availability就差“点”，
NoSQL差的地方不是一点了，
小心有一天NoSQL也终于支持SQL statement那就是笑话了，
呵呵。 |
|
s*****r
发帖数: 43070 | 21 所以俺不看好Oracle，这些transaction data，至少historic的，放进nosql没有什么
问题，query时候搞两次就好，一个去Oracle找最近的，一个去nosql找老的。麻烦是
join，但join on历史数据的要求并不多，主要是报表才需要，这个也可以用nosql来解
决。
如果hibernate开始支持CQL，Oracle估计可以砍掉一半人。 |
|
o**1
发帖数: 6383 | 22 我觉得 nosql 对oracle肯定冲击会很大，只会越来越大。
之前大家没选择，以后很多 application 会选用 nosql 的，因为很多应用数据不是那
么 critical. nosql 速度又快，扩展也容易，又便宜，不用才怪呢。 |
|
t*******e
发帖数: 684 | 23
"given a key, to get the value(s), 本身就是最典型的ad-hoc query. 是每个nosql
最基本的功能，否则要他做什么？distributed file system 就可以了。你说nosql
not support ad-hoc query, 任何相关领域的人都得和你急。"
如果你这么认识ad hoc query，我也无语了。另外你举的Digg的例子，没见人说是
cassandra failed the project，都说是inadequate test导致的。我没用过HBase, 但
google hbase vs cassandra 出来的结果和你说差别很大。不相信可以自己试试，不要
说这些人也都不如你hands on。
我现在在evalute NoSQL databases，决定前就想多看点，避免一面之词。 |
|
c******o
发帖数: 1277 | 24 除了适当缓存以外，这个当然可以换nosql
nosql没有join是因为join本身就slow （相对来说）。
nosql的设计就是要denormalization, 有冗余,把数据放多个地方，不用join，可能
consistency/transaction 会麻烦，但是快，容易scale |
|
c******o
发帖数: 1277 | 25 除了适当缓存以外，这个当然可以换nosql
nosql没有join是因为join本身就slow （相对来说）。
nosql的设计就是要denormalization, 有冗余,把数据放多个地方，不用join，可能
consistency/transaction 会麻烦，但是快，容易scale |
|
z****e
发帖数: 54598 | 26
like i said
"一般ui的更新是最频繁的
最不频繁的是数据持久层，从db到nosql用了多久
而且大量db还在使用中，nosql可能永远都无法替代db"
i believe db will never be deprecated
nosql is just another option of traditional db
but we still need db to handle transactions etc.
but for the ui part, deprecation probably has already happened
who really care about the web now?
it sucks, it does not generate profit
most of web companies r dying
the pc sales r going down recently
and those companies r laying off monkeys
mobile is the future, if u dont c this
u ... 阅读全帖 |
|
z****e
发帖数: 54598 | 27
like i said
"一般ui的更新是最频繁的
最不频繁的是数据持久层，从db到nosql用了多久
而且大量db还在使用中，nosql可能永远都无法替代db"
i believe db will never be deprecated
nosql is just another option of traditional db
but we still need db to handle transactions etc.
but for the ui part, deprecation probably has already happened
who really care about the web now?
it sucks, it does not generate profit
most of web companies r dying
the pc sales r going down recently
and those companies r laying off monkeys
mobile is the future, if u dont c this
u ... 阅读全帖 |
|
z*******3
发帖数: 13709 | 28 大神你吹了这么久其他领域
要不说说有什么好用的产品吧
java已经攻下了nosql和mapreduce两个肥缺
facebook贡献了cassandra
yahoo贡献了hadoop
两个都是java做的
这两个在nosql领域把c++写的mongodb干得死去活来
现在说nosql war，都是cassandra vs hbase，mongodb作为先行者
多少已经落伍了，mongodb的缺点很明显，就是要把所有的索引全部读入内存
这个一旦数据量上去，会有其局限
还有就是scala，akka等也在攻占电信等领域
这都是jvm上的盟友啊，二爷说的那个play我看了下
貌似就是冲着你们web去的，如果连web都守不住
那还有什么可以说的呢？
没有产品，说什么都是空的
python这么多年，我记住的稍微像样的产品就是一个django
还经常跟电影搞混，你说这个是不是有些问题
啊？
你说的那个orm，那都是j2ee十年前的东西，当时hibernate风行全球
hibernate是我们这边一个学数学的monash大学毕业生搞的
玩剩下的，jpa标准我看他都已经没啥可搞了
说类库多的话，问你一个... 阅读全帖 |
|
c****e
发帖数: 1453 | 29 "mongodb的缺点很明显，就是要把所有的索引全部读入内存"
不能全部放入内存也可以。会swap out。如果是顺序处理，对性能影响不大。
"这两个在nosql领域把c++写的mongodb干得死去活来"
MongoDB没有比Cassandra先行，现在社区比Cassandra还活跃。NoSQL的发展正在和SQL
融合，原来视为原罪的transaction也在找回自己的位置，特别是in-memory越来越流行
了。 Cassandra攻下noSQL,Java原教旨主义都不敢这么说。 即使Hadoop, 对于大数据
处理，也是一个方面的工具。MPP和Mapreduce都有自己的位置。 |
|
z*******3
发帖数: 13709 | 30 大神你吹了这么久其他领域
要不说说有什么好用的产品吧
java已经攻下了nosql和mapreduce两个肥缺
facebook贡献了cassandra
yahoo贡献了hadoop
两个都是java做的
这两个在nosql领域把c++写的mongodb干得死去活来
现在说nosql war，都是cassandra vs hbase，mongodb作为先行者
多少已经落伍了，mongodb的缺点很明显，就是要把所有的索引全部读入内存
这个一旦数据量上去，会有其局限
还有就是scala，akka等也在攻占电信等领域
这都是jvm上的盟友啊，二爷说的那个play我看了下
貌似就是冲着你们web去的，如果连web都守不住
那还有什么可以说的呢？
没有产品，说什么都是空的
python这么多年，我记住的稍微像样的产品就是一个django
还经常跟电影搞混，你说这个是不是有些问题
啊？
你说的那个orm，那都是j2ee十年前的东西，当时hibernate风行全球
hibernate是我们这边一个学数学的monash大学毕业生搞的
玩剩下的，jpa标准我看他都已经没啥可搞了
说类库多的话，问你一个... 阅读全帖 |
|
c****e
发帖数: 1453 | 31 "mongodb的缺点很明显，就是要把所有的索引全部读入内存"
不能全部放入内存也可以。会swap out。如果是顺序处理，对性能影响不大。
"这两个在nosql领域把c++写的mongodb干得死去活来"
MongoDB没有比Cassandra先行，现在社区比Cassandra还活跃。NoSQL的发展正在和SQL
融合，原来视为原罪的transaction也在找回自己的位置，特别是in-memory越来越流行
了。 Cassandra攻下noSQL,Java原教旨主义都不敢这么说。 即使Hadoop, 对于大数据
处理，也是一个方面的工具。MPP和Mapreduce都有自己的位置。 |
|
z*******3
发帖数: 13709 | 32 我们这边在大学上课
举例子的时候，说一个项目失败
最常见的例子就是说如果项目用到主机
找不到做cobol的人
那项目就会失败
cobol的人很难找，本身工作机会就不多
做的人更少，所以hr要挖一个做cobol的人
经常要花上半年以上时间去打广告去准备
那些做cobol的也不愿意动，都懒得要死
相比之下，dba和nosql的好找很多
尤其是nosql，一般都找开发做
db的transaction什么的到了超大系统的时候会成为瓶颈
nosql的精度太低，涉及到钱的交易就难堪大任，适合web公司
mainframe能搞定精度和超大数据，但是维护成本是主要问题
不是有钱的主烧不起，所以各有利弊，看不同行业 |
|
d*******r
发帖数: 3299 | 33 我还在琢磨搞个什么idea，二爷已经搞出来，惭愧了...
前一个星期都在乱看些 noSQL database, 把流行的noSQL database的都看了一下.
Redis (C) 很流行的样子，好像多用在内存里面做缓存, 不算专门的Database.
CouchDB (Erlang), 据说迁移和 Peer Backup/Synchronization 功能非常好. 看了下
他们公司的产品感觉很多很晕，新合并了公司，现在有个CouchBase貌似包括了CouchDB
的功能.
还看到一些游戏公司(e.g. Rovio) 在用 Riak (也是Erlang写的，multiple data
center deployment 要按node收钱).
http://vimeo.com/65582437
看到最后，貌似这2个组合用的人最多最流行?
Node.js + MongoDB(C++) for quick prototyping
Java/Scala + Cassandra(Java) for serious players
Cassandra 很多大公司用，看着很靠谱的样... 阅读全帖 |
|
g*****g
发帖数: 34805 | 34 NoSQL意思是Not only SQL，通常是RDMBS不够用，特别是HA要求高的场合用来补充用的。
否则RDBMS从transaction support, queries, tools, stability各方面都是秒杀NoSQL。
当数据量那么小，完全没有HA的需求的时候，非去用NoSQL就是给自己找麻烦。 |
|
g*****g
发帖数: 34805 | 35 很好的文章。说到底高并发最后的主要问题都在数据库的处理上。传统RDBMS很强大很
方便，但不scale out。解决方案就是把不需要transaction的部分拿出去扔到cache和
NoSQL里，把所有非存储的商业逻辑扔到app server上 (不用stored procedure)。把需
要transaction的部分尽量水平和垂直上划分使得单个RDMBS需要处理的数据量尽量小。
还不够的话只能批量处理transaction但这时候就会产生一些consistency的问题。架构
最大的难度，在于如何划分数据库，用什么样的cache和NoSQL，这些都是跟数据的特性
相关的。不同数据对CA的容忍度不同，需要对商业逻辑有深入理解以及不同Cache/
NoSQL有深入经验。 |
|
g*****g
发帖数: 34805 | 36 从数据库实现的角度讲，NoSQL DB不见得比传统数据库更复杂。
但从开发者的角度来说，NoSQL比RDBMS复杂太多了。RDBMS大同小异，而常见的NoSQL
就有10个左右。挑一个合适的本身就很见功底。
reduce |
|
g****r
发帖数: 1589 | 37 看你干啥，你要是想用NoSql搞ACID，那你绝对NB。但大部分用NoSql的基本就是当data
ware house或者是存trace用的，真谈不上有啥复杂的，而且NoSql就那几种类型，key
-value，document，table column，graph，每个类型里面也就那个几种，真需要用需
要决定选哪个，网上那么多技术博客、论坛，google半小时差不多就知道那个更合适了 |
|
T*****e
发帖数: 361 | 38 同意。NoSQL也不是什么问题都能解决，网上骂NoSQL的也不少，但是这种应用的确是它
们的强项。
goodbug做这个，有这方面的经验，很自然就往这方面想。有些对NoSQL以及cassandra
没有太多的了解，是不容易明白这个方案的好处。 |
|
g*****g
发帖数: 34805 | 39 像淘宝这样的商品网站，一个transaction就是可以和不可以用的区别。NoSQL的使用是
有局限的。
大型网站用sql和nosql混合的策略，对症下药来提高性能，小网站一个mysql DB加一个
read replica备份足够了。
NoSQL本来就是No only SQL. |
|
d*******r
发帖数: 3299 | 40 我个人还是觉得 NoSQL 方便，SQL 没事把一堆正常的数据结构倒腾成一堆 SQL 语句和
table rows (不带 nested fields 那种), 然后再倒腾回来，来回倒腾... 真心郁闷
死... 从来用这个就难受。当然，有各种 ORM 帮助我们，但是我何必要多此一举呢。
我觉得回头新的 NoSQL 自带些简单有限的 transaction 功能，就完全不需要 SQL 了
。我现在在 NoSQL 上做一些复杂的 transaction-like 的操作的时候，宁愿自己在内
存里面实现几个简单的 customized locks，我都不愿意倒腾 SQL 和 table rows. 当
然，SQL 做大项目还是比较靠谱的，因为成熟稳定。
使用 |
|
d*******r
发帖数: 3299 | 41 确实是 SQL 现成功能多呀，但是我觉得 SQL 有时也需要修改 schema 呀，如果需要改
的话，比 NoSQL 更麻烦吧。
规划 NoSQL cluster 上的数据，是因为 NoSQL 才有这个能力吧。
我觉得 SQL 要 scale 的话，估计也得做这些？只是 SQL 自己内部做了，我们 app
developer 控制不了？
我其实没用过 SQL 做过大的东西，请教下 SQL scale 的时候，一般都有哪些 option
？我是说不用 AWS RDS 的情况下. |
|
t******o
发帖数: 34 | 42 因为嵌入方便，现在的数据处理工具本身自带函数不够用，作为扩展，数据库 和
nosql/dremel数据库就 允许你通过 lua来定义查询和关联功能，你都可以用 lua 来动
态生成数据表，sql/nosql执行的时候灵活很多，大大提高了日志数据的处理能力，甚
至你可以 把 R中的很多功能在nosql上实现，这个处理 pb级别数据的时候非常有用 |
|
r***y
发帖数: 4379 | 43 多谢朋友分享.
大牛的推荐是不是说尽量减少 RDBMS 的负载. 仅仅让 RDBMS 干跟 transaction 有关
的.
主要负载都扔给 nosql .
这样 RDBMS 部分基本没太大负担, 就免去 scaling 的折腾.
仅仅对 nosql 部分做 scaling , 而这又是 nosql 的强项.
btw, "一个ca和一个ap系统做配合" 中 ca/ap 是指啥呀? |
|
z****e
发帖数: 54598 | 44 lol
解释这么多
给你一个名词
就是checking嘛
如果你对transaction机制有所了解的话
这个东西早被人做烂了
我还以为是啥高大上的牛逼算法呢
原来就这破烂？
哎哟，你不说我还忘记了
这个逻辑用java一样实现
不用c我一样可以做出来
但是这个性能上的提升十分有限
除了装逼没鸟用，尤其是内存
如果我没记错的话，cassandra等nosql用得比较多
关于这种transaction的判断
有三种我记得，forward checking, backchecking还有一什么叉叉
忘了，一般因为硬盘上这种东西比较容易发生错误
所以主要是persistence时候用，内存不搞这个
内存中的操作以简化线程机制为主，只有分布式存储才会有这种问题
因为无法简化线程和进程之间的冲突，它一定有冲突
原理其实也很简单，就是用一个time stamp来替换lock
当你读的时候，看一下time stamp，然后当你update的时候
另外写一块，完成之后，看原来的time stamp是否被修改过
如果没有，直接用一个原子操作，把ref修改到新的地址块中去
实践中，只有nosql和db等pe... 阅读全帖 |
|
p*****2
发帖数: 21240 | 45 优缺点都明显
有点是document nosql跟node配合无缝
功能最强大nosql 跟 sql最接近
in memory performance好
ha sharding 自动支持
缺点是太占memory scale不方便 跟其他nosql比起来显得很昂贵
但是具体用什么要看use case了
我发现一个问题就是很多人设计系统都想一个东西解决 我一般是在mongo redis
cassandra中综合考虑 很可能三个都用 |
|
w**z
发帖数: 8232 | 46 我已经说了，nosql 大多不support transaction。 你非要说DB 一定support
transaction， 那只说nosq， 不提l database 好了。
为什么nosql 会那么火，因为RDMS 不能support 那么大的throughput， transaction
是其中重要的原因。 这不都是有关联的吗？ nosql 和 RDMS 是有不同的use case，
没必要，非说那个好，那个不好。你说的 support ACID 的 open source DB project
是哪个？ |
|
z****e
发帖数: 54598 | 47 可能hdfs也值得带走吧
hbase就算了吧，不太想用
postgre+cassandra+flink
应该可以满足绝大多数需要了
flink可以替换掉yarn, spark, storm & hdmr
cassandra，postgre可以替换掉hbase，mongo
剩下的交给vert.x
酱紫大概用4-5个框架，就可以解决几乎所有目前已知需求
sql/db, nosql/batch, streaming, script, web, web service, thread pool etc.
如果将来有一个vert.x based & flink-like system
而非akka based systems(spark&flink)
那就是一个终极解决方案，要有人这么搞就太好了
话说nosql真麻烦啊
一般db的话，一个jdbc就搞掂了，顶多说异步的话，需要启一个worker
但是nosql还要折腾mr，yarn, spark, flink这些，麻烦不少 |
|
z****e
发帖数: 54598 | 48 vert.x看懂了之后，你再看node.js, akka这些都不难
vert.x里面就把大多数流行的东西都给整合到一起去了
nosql那些你得用了才行，一个建议吧
nosql对于大多数领域来说，不如web那样有那么多无结构数据
但是有一个一定是无结构的，那就是log
你可以用nosql比如干脆就用file system比如hdfs存log
然后内部用lucene做一个搜索引擎
查log之类的，很方便，顺便lucene还可以查xml, html, text这些 |
|
z****e
发帖数: 54598 | 49
vert.x, nosql这些都是概念上完全跟你以前接触的不是一回事
应用领域也截然不同，搞java的应该都清楚，同类型的产品
比如都是db，懂一两个就足够了，其他都是举一反三的，所以就不会问太多细节
没有意义，但是如果概念上完全不一样，那就没有办法举一反三了
db的用途跟nosql的用途不是一回事，虽然nosql将来有发展成db超集的可能性
但是我个人感觉，这还很遥远，而且是不是真能实现，也很难说
vert.x，akka这些跟spring，ejb这些不太一样，多一种选择总是好的 |
|
M*****n
发帖数: 2301 | 50 吵了半天终于有个可以看的link了
好虫的方案就是典型的NoSQL DB的东西，star replication， commit after
quorum writes，failover to new master after election, 这些没什么可以说的。
貌似魏老师的方案属于chain replication， 这种replication用的比较少，但是也有。
相对于star replication，chain replication也有自己的优势，就是master
负载小一些。
不过我没有看明白魏老师的设计里面，何时给client这个commit，看魏老师的意思
三段DC之间的replication是async的，这样如何保证不丢数据 if master fail？
如果replication是sync的，write只有到commit到backend server，txn才
算commit to client，这类似于NoSQL里面consistency model = ack from all nodes，
在NoSQL里面这种write latency是蛮大的，在魏... 阅读全帖 |
|
