g**e
发帖数: 6127 | 1 同意。这几天在想如何在dynamodb上实现atomic update两个表的item，搞来搞去最后
还是只有做自己的journal system.
single
on
can |
|
s*******r
发帖数: 35 | 2 请问大牛们，在AWS如何作测试，像junit。我们要用SQS,DynamoDB,CloudSearch等等，
不容亦mock。我能想到的就是在AWS app 上专门开一个webservice endpoint作test用
，然后本地机器用curl发request 到那个app，drive 测试logic.
请大牛们给些idea. goodbug? |
|
x****d
发帖数: 1766 | 3 I see what you saying now. cool. I don't know when we are going to use those
things from AWS. How your company decided to use DynamoDB? Any concerns? I
guess it is off topic, just curious. |
|
c****e
发帖数: 1453 | 4 瞎吵吵之前，先想清楚定义。现在的背景下，底层的涵盖也在扩大。OS算，driver算不
算？做file system replication算不算？ cloud storage算不算， 做virtulization
的算不算？
这些的package非常高，也到处缺人。至于机会，系统的工作永远比应用的少。同时找
人的话对于经验的需求也高一些。说几个底层的例子：
（1） 给你1000台机器，怎么弄个dynamoDB出来？ 就算是在mysql上partition攒出来,
没个几年经验入不了门。
(2) 网络速度太慢了，rack机器可以用fiber直接connect,怎么自己优化protocol。
(3) 运算太慢了，要用专门的芯片协处理。为了在线更新方便，用FPGA。一个
datacenter里面的机器上这个，比run hadoop job有意思吧。
做什么都行，做自己擅长的事情。如果水平一般随大流的，奔着热门的找没错，
openning至少多很多。 |
|
p*****w
发帖数: 429 | 5 我支持你的观点，提个醒这些更偏infra不是底层。
瞎吵吵之前，先想清楚定义。现在的背景下，底层的涵盖也在扩大。OS算，driver算不
算？做file system replication算不算？ cloud storage算不算， 做virtulization
的算不算？
这些的package非常高，也到处缺人。至于机会，系统的工作永远比应用的少。同时找
人的话对于经验的需求也高一些。说几个底层的例子：
（1） 给你1000台机器，怎么弄个dynamoDB出来？ 就算是在mysql上partition攒出来,
没个几年经验入不了门。
(2) 网络速度太慢了，rack机器可以用fiber直接connect,怎么自己优化protocol。
(3) 运算太慢了，要用专门的芯片协处理。为了在线更新方便，用FPGA。一个
datacenter里面的机器上这个，比run hadoop job有意思吧。
做什么都行，做自己擅长的事情。如果水平一般随大流的，奔着热门的找没错，
openning至少多很多。 |
|
w******f
发帖数: 620 | 6 我碰巧是在这两个领域都做过，app 层在A做AWS EC2 DynamoDB, 系统层做kindle 和
kindle fire. 我觉得大家要有肚量，没有一个人是什么领域都牛B，没有一种办法对所
有的问题都最优。
如果说是春运的订票出票是象老魏说的那样高耦合，魏老师的办法显然要好，说到底分
布式还是不能把高耦合的东西分开，所以瓶颈还是在单机的处理速度。 |
|
s*******r
发帖数: 35 | 7 请教大牛们哪个会更好？用Asgard的话能不能把 the entire deployment from Asgard
translate to scripts (and from script to Asgard), so when building a new
environment (or recovering from disaster) we don't have to do it from
scratch again?
Another question, can Asgard be used to create dynamodb, cloudsearch? or we
need to use template/cli to do that?
Our app is somewhat complex, about 30 individual services, each in its own
ASG - but probably not nearly as complex as Netflix?
Thanks. |
|
g*****g
发帖数: 34805 | 8 Asgard is a UI tool, and a very good one. If you are looking for scripts,
you should use scripts.
Asgard wraps around scripts. I don't think Asgard supports DynamoDB or
CloudSearch since Netflix don't use them.
Asgard
we |
|
c***d
发帖数: 996 | 9 你们单位真郁闷啊， 让你研究这个。
现在后台这几个颠覆性的技术， hadoop是google big table paper出来的， ec2 是阿
麻 dynamodb出来的。 mongodb的10gen后面也有一批大公司出来的人， 微信在美国流
行不了是因为它抄whatsapp， 你去看看whatsapp的人是从哪来的。dropbox里面都是
mit的， 可box里面都是些烂学校出来的。 就说twitter, 前两年cto都跑了， 眼看着
不行了， 谁想到上市这么火。
硅谷的事情总结起来就俩字： 没准。 |
|
|
s******n
发帖数: 48 | 11 我们是在AWS上搞一些专门针对教育的cloud services。你把EC2/S3/DynamoDB这些直接
给学校谁会用呀？
我们不强调线上线下，更强调方法和工具。我们的东西线上线下的教育机构都可以用。
与传统线下和现在主要的线上教育不同的地方是用互联网的方式教学和学习，强调实时
互动，统计分析这些。 |
|
c******o
发帖数: 1277 | 12 我现在是aws的fans,觉得要不是真的特殊要求，nosql上， aws的dynamodb,
elasticache足够了，又便宜又方便。redshift还能join
新的kinesis也很酷，正在研究。 |
|
b****y
发帖数: 169 | 13 湾区小公司。感兴趣请给我发站内邮件。
谢谢。
Job Description
• Support an always-available cloud-based SaaS platform
• Support application deployments, building new systems and
upgrading and patching existing ones.
• Develop automation to quickly and rapidly deploy instances from
hardened images
• Using monitoring tools to find problems, resolve and/or escalate
to development and ensure that we exceed our SLAs
• Build and manage development and testing environments, a... 阅读全帖 |
|
|
w**z
发帖数: 8232 | 15 Cassandra 一般RF 设成3，就不需要专门backup 了。一个node 挂了， 换个上去就行
了。 有了 vnode， 就更方便了。
devopt |
|
p*****2
发帖数: 21240 | 16
照你这么来说，mongo也不需要backup了吧？ |
|
c******o
发帖数: 1277 | 17 there is always case you need backup, restoration
I just did one for our sandbox, some developer accidentally dropped one db.
so if you need to put it back "consistently" in sharding env. it is always
hard. |
|
|
|
w**z
发帖数: 8232 | 20 backup 还是有的，好像Cassandra 本身带这功能。在production环境里，还没用上过
。backup只是在disaster recovery 时才用得上。一般不会在production 里乱来的。 |
|
g*****g
发帖数: 34805 | 21 Daily backup是必须的，要不然整个cluster挂了麻烦了。最显然的就是一个雇员不爽，
就能把整个公司最有价值的数据都弄没了，这个事情是必须避免的。 |
|
h****r
发帖数: 2056 | 22 你们的mongo能scale到那种程度？存同样的数据，mongo还是太耗storage。 |
|
c******o
发帖数: 1277 | 23 两个都是unlimited linear scale. no limit
storage 太cheap了，比起人工和软件费用。 |
|
w**z
发帖数: 8232 | 24 Cassandra的index 最好还是别用。 |
|
w***g
发帖数: 5958 | 25 就是像你说的这样，create table的时候把key设计好。如果不行的话就重新create
table再把数据导过去。Cassandra这类分布式的key-value store和传统数据库设计理
念不一样，所以用法也是不一样的。传统的key-value store的index一般就是B+-tree
或者hash table。这两者都假设random disk access，一旦cache不够用了并行读写甚
至单线程读写也就完蛋了。重新导一遍几十G的数据库都很费时费力了。而Cassandra的数
据据我的理解是按log方式存储的，也就是说新的数据来了就往文件最后面添加。这种
情况下就增加了建index的难度和性能。好处则是数据写入非常有效，而且因为有多台
机器多个硬盘同时读写，重新导一遍数据就跟玩似的。而且因为用的廉价硬盘，空间极
大，不在乎多保存几个copy的数据。新兴的互联网公司有点前途的都是指数增长的，也
就是说一个时间段新增的数据量基本和之前所有积累的数据量相当，所以隔断时间重新
导一下可以作为一个常态。
MongoDB跟Cassandra很不一样，更接近传统数据库的设计，... 阅读全帖 |
|
c******o
发帖数: 1277 | 26 mongodb的scalability不差，我们prod上用了一段了，挺好。
加shard很容易，lock也不是问题。
说起来，scalability还好，但是availability不如cassandra, 主要还是注重
consistency了。而且document db比column db， 小地方用起来方便多了。
mongo
sharding key选的不好没法改，而且对performance影响很大，最后也是重导入一遍，
我们刚刚对一个collection干了一次。 |
|
d*******r
发帖数: 3299 | 27 MongoDB 的易用性真是没的说
不知道 10Gen 啥时候能出个去掉 db-level lock 的新版本。
看他们 blog，貌似在开发这个。 |
|
g*****g
发帖数: 34805 | 28 This blog sums up the problem pretty well. You better know what you are
doing before using secondary index, particularly on big dataset.
http://www.wentnet.com/blog/?p=77 |
|
|
|
h****r
发帖数: 2056 | 31 They started to work on it since 01/2013, guess it is a hard issue to them. |
|
d*******r
发帖数: 3299 | 32 那看来公司同事用的 RDS 是 AWS 帮他们 scale up, 不能 scale out 了
其实我是 SQL 弱，而且很不喜欢用 SQL，所以我的项目里没有 SQL, 都是用 mongoDB,
dynamoDB 之类的 |
|
|
g*****g
发帖数: 34805 | 34 跟Cassandra比较接近，好处是managed service. |
|
d*******r
发帖数: 3299 | 35 刚刚翻了很多Java旧帖子，大牛说的是.
准备回头认真学学Java后端, 貌似从Spring boot入门最好?
我C/C++/Python/Node.js都有实战基础,Java基本只是用整个的轮子(ES,DynamoDB之类).
还有些旧帖子提到，有些很需要稳定性的GUI相关逻辑，还需要Spring MVC来写?
貌似用 JS SPA (e.g. Angular, React) + Java RESTful (e.g. jersey) 也能搞定吧. |
|
s*********s
发帖数: 35 | 36 我们是用kinesis接受数据，再由spark streaming做一些数据处理，然后请教大牛们两
个问题，
1）从spark streaming 如何直接存到 dynamo （Cassandra就有一个很好的connector
，datastax开源的，可惜头一定要production用dynamo）
2）如何从dynamo 读 数据到 spark 做 batch 处理
谢谢 |
|
P****i
发帖数: 12972 | 37 直接用aws java/scala sdk不行吗？
connector |
|
z****e
发帖数: 54598 | 38 这个要问amazon了
你们为啥会用dynamo呢？
这个东西会导致vendor lockin
公司里谁被amazon的sales忽悠了吧？ |
|
c*****a
发帖数: 1638 | 39 写很简单。我没看懂你有啥困难的？在function里面直接写就行了，只是要注意控制
provision
通俗点就像在MR里面在mapper里面开连接写就是了。
读会相对比较麻烦。如果你是说scan的话，2种做法吧，数据量不大就在driver里面读
。数据量大的话就分片到每个tasks里面，然后返回RDD。
dynamo用起来不便宜，如果你们确定数据量很大，其实Cassandra可能更好。但是如果
你们现在没有已有的Cassandra，那么可能TCO Cassandra更贵就是了，因为dynamo你们
可以不用Admin。
connector |
|
|
s*********s
发帖数: 35 | 41 可能头不想我们承担数据库方面的风险吧 如果数据库方面出问题，就不是我们的责任了 |
|
s*********s
发帖数: 35 | 42 被你这么说 好像写是挺简单 只要用dstream的map函数 在里面写输出是吧 我回头去试试
读的话我原本也是担心是转换 我看到网上一个贴说用dynamoInputFormat转HadoopRDD
可能确实是Cassandra更好也说不定 但是用dynamo已经是板上钉钉的事。。
这周的strata 好像也是spark最火 |
|
l*****7
发帖数: 55 | 43 用AWS DynamoDB
1. 设计好key和index
2. 选择合适的throughput, 需要观察一段时间，选择成本和性能的权衡
3. 访问数据库时减少scan, 想清楚需要read的强一致性和弱一致性，选择精度和成本
的平衡
你有40K用户时，只需要设定一个更高的throughput，真正的的scale就是你不用scale
任何东西。
replication
4k |
|
d*******r
发帖数: 3299 | 44 恩, 是 JVM. 不过我近来经验觉得, 很多时候其实是在设置 Java-based service,
比如 dynamoDB, ES (或者你用的 Spark), 可能需要调下 JVM 参数.
不过调用这些 Java-based service 写公司自己的 service/application 的时候,
因为各个语言的 bind 多, 还不用写 Java. |
|
d*******r
发帖数: 3299 | 45 要看你怎么用 AWS. 我一直避免使用 AWS only 的应用, 比如 DynamoDB, 甚至是 ELB. |
|
d*******r
发帖数: 3299 | 46 但是 DynamoDB 只能在 AWS 用, 就 lockin 得太厉害了 |
|
N*****m
发帖数: 42603 | 47 elb问题不大，基本上大的云服务商都提供LB
大不了自己搞个HAProxy
DynamoDB可以避免
ELB. |
|
