发帖数: 1 | 1 单机肯定不行，只能做原型验证
但是淘宝卖东西的商家千千万，商家都是独立无关连的，所以很容易把请求分散到不同
机器，再加上大部分操作只是显示网页，不是下单，就是只读而已，很多东西就在内存
，所以4200万次也就是分布式刷网页
真的涉及到写磁盘，也就20几万次而已 |
|
|
发帖数: 1 | 3 还他妈的没有任何复杂性
。。。
自以为是的傻逼真多， 真以为写个pet shop store 就知道大并发怎么玩了啊 |
|
p********1
发帖数: 2785 | 4 可以跟火车购票系统比较一下。但某些人强以不知为知就不对了。 |
|
l******t
发帖数: 55733 | 5 这么没复杂性的玩意差几个数量级的亚麻就能让你看一天狗 |
|
|
发帖数: 1 | 7 火车票订票比这个复杂。
火车票是联动的，因为中间有换乘站，还有枢纽车站，相互之间都是由关联性的
淘宝商家都是独立的，我卖的和你卖的没任何关联，如果愿意，每几万个商家搞一个数
据库都可以。除了搜索麻烦一点，前面根本看不出，就变成完全分布了。 |
|
发帖数: 1 | 8 这么大的量， 请求分布到不同服务器上， 也不是件容易的事吧。 能做到极致也蛮牛
的吧 |
|
发帖数: 1 | 9 有人提到股票系统, 有人提到火车飞机定票系统, 也就是说并没有什么新技术, 没什么
可吹的, 而且更加复杂的技术早就在那里, 1111只是量大, 还分流了, 鸭妈没搞分流,
不小心down机了. |
|
a********c
发帖数: 3657 | 10 看来菌斑都是民科。。。这就是阿里的big table实现，10年从狗狗弄了几个马龙搞得
，百度也有。 |
|
|
a********c
发帖数: 3657 | 12 就是partition。。。搞这个人在国内开了培训班，天天挂嘴上说，其实真正的发明者
是狗狗的一个牛三哥
：分partition不就完了？
： |
|
发帖数: 1 | 13 这和数据库是什么无关。
有些东西很容易想的，成天想着婆婆妈妈的技术细节，就不知道其实大方向非常容易看的
数据库交易要写磁盘的，为了可靠性，不能丢，磁盘写入IO速度多少，所以瓶颈很容易
找到，数据库交易数量不行，就因为这个，闭着眼睛也能猜到
所以设计根本不要用普通数据库，因为那些都是为了读写在一起设计的。
把读写分开就行了，读可以都放在内存，速度立刻就上去了。只要做好数据同步就行了。 |
|
s***h
发帖数: 487 | 14 Postgres 和 MySQL 还有 MongoDB 都是 open source 的。你自己写一个能写得更好？
: 这和数据库是什么无关。
: 有些东西很容易想的，成天想着婆婆妈妈的技术细节，就不知道其实大方向非常
容易看的
: 数据库交易要写磁盘的，为了可靠性，不能丢，磁盘写入IO速度多少，所以瓶颈
很容易
: 找到，数据库交易数量不行，就因为这个，闭着眼睛也能猜到
: 所以设计根本不要用普通数据库，因为那些都是为了读写在一起设计的。
: 把读写分开就行了，读可以都放在内存，速度立刻就上去了。只要做好数据同步
就行了。
|
|
|
|
r******n
发帖数: 4522 | 17 有这个需求，才值得投钱搞，但不是啥高难度，属于投入必有产出的，高铁也是。 |
|
g******t
发帖数: 11249 | 18 要是对速度要求这么高的话
干脆别用database了，直接access file更快
淘宝交易也相对独立吧
看的
了。 |
|
发帖数: 1 | 19 尼玛这用得着从头全部重写吗？
怎么设计我都说了，我根本不是做数据库的，都能看出来应该怎么做，思路多容易，我
已经说了，读写分开。
所以主要工作就是做好数据同步就行了，因为写入以后数据变化，和读的一侧保持同步
就可以了。
同步实时性要求没那么高，慢个几秒，刷网页的时候有几秒看着不一致，没啥关系，人
有不是机器，谁会揪着不放，过几秒就好了 |
|
g******t
发帖数: 11249 | 20 贵啊
米帝请一个架构师怎么也得15万
程序员8万
一个团队一年没百多万下不来 |
|
s***h
发帖数: 487 | 21 哪那么容易自己写一个。如果美帝把 open source database 一掐，鳖的 database 基
本就不会再升级了。
: 要是对速度要求这么高的话
: 干脆别用database了，直接access file更快
: 淘宝交易也相对独立吧
: 看的
: 了。
|
|
s****r
发帖数: 68 | 22 复杂性在于super high qps，人可接受的response time，和transaction。当然如果不
进入购物车，显示的一个商家的信息可能略微stale。
就不要纠结磁盘了。你去看看提供人可接受的响应时间的系统，serving side critial
path的数据有几家还用磁盘的。最多SSD。去看看google，fb，amazon。现在所谓的
database已经不是传统的database了。
QPS and response time就是复杂性，reliable（不crash）就是做得不错。
看的
了。 |
|
g******t
发帖数: 11249 | 23 要是政府的话
花钱找个教授，叫兽找个研究生
改吧改吧就是国产自主创新数据库
搞不好还能评个国家科技进步奖 |
|
g******t
发帖数: 11249 | 24 可以加一层transaction server
critial |
|
s***h
发帖数: 487 | 25 哥们你不做数据库为啥这么热衷嘛？
: 尼玛这用得着从头全部重写吗？
: 怎么设计我都说了，我根本不是做数据库的，都能看出来应该怎么做，思路多容
易，我
: 已经说了，读写分开。
: 所以主要工作就是做好数据同步就行了，因为写入以后数据变化，和读的一侧保
持同步
: 就可以了。
: 同步实时性要求没那么高，慢个几秒，刷网页的时候有几秒看着不一致，没啥关
系，人
: 有不是机器，谁会揪着不放，过几秒就好了
|
|
发帖数: 1 | 26 用户还要搜索商家，所以用文件麻烦，虽然不是不行
这个设计其实也有trick，很容易看到的，搜索看着几十页，其实显示给你的只有1页，
后面是什么也没人知道，其实也是天然分布式 |
|
l******t
发帖数: 55733 | 27 笑劈了。你属于菌版病情比较严重的，整体特征是话痨，不知所云 |
|
|
发帖数: 1 | 29 我只是证明设计思路很容易，工程的东西，其实都很容易的 |
|
l******t
发帖数: 55733 | 30 你得先证明你能实现transaction。google的搜索比起来是狗屁。和那个时瘫一样逗逼 |
|
g******t
发帖数: 11249 | 31 但是银行是找IBM花了大钱设计出来的
咨询费每年砸几亿吧
taobao用开源自己改，对工程师要求很高
至少是google/facebook水平的 |
|
s***h
发帖数: 487 | 32 其实不如直接用 open source，加雇海量便宜五毛人肉电池。
哥们太理想主义的，在国内可能会被迷奸得找不着北。
: 要是政府的话
: 花钱找个教授，叫兽找个研究生
: 改吧改吧就是国产自主创新数据库
: 搞不好还能评个国家科技进步奖
|
|
发帖数: 1 | 33 大公司愿意卖高价，是他们的本事，高价不见得复杂。
顺着这个思路，终归做的好，有什么理由做不好呢？思路错了肯定完蛋了。 |
|
|
g******t
发帖数: 11249 | 35 IBM主机是软硬件一体化的解决方案
硬软件/网络甚至电源空调系统都为大规模交易优化过 |
|
|
s***h
发帖数: 487 | 37 Google 用 big table，Facebook 用 Apache Cassandra。当然都是听说。
但那些是 NoSQL，不是 ACID compliant，不适合火车订票系统我想。
: 是不是知道MySQL就感觉牛大了？这是幻觉:-)
: 你从哪里听说YouTube用mysql？Google还在用MySQL吗？人自家的big table，
spanner
: 都出来多久了https://ai.google/research/pubs/pub39966, https://en.
wikipedia.
: org/wiki/Spanner_(database))。
|
|
发帖数: 1 | 38 他这么说肯定是骗用户的。
大规模交易瓶颈就是磁盘写入速度，其他都不是瓶颈。他能找到IOP很高的磁盘，算是
优化，其他都是骗用户，卖更高价钱的 |
|
s****r
发帖数: 68 | 39 不同业务有不同需求：search的transaction语意不强，可以不要ACID的transaction。
但广告，怎么也得是ACID吧。 |
|
g******a
发帖数: 778 | 40 这太吓人了？有没有确切的出处？
：结果大部分写手都得过痨死了
： |
|
s*****r
发帖数: 43070 | 41 交易肯定是有写的，只读不需要接触数据库，用cache就能解决好
实时更改的transaction应该就是用户的balance和order的status，其他工作都可以在
线下批处理完成，比如shipping
用户的数据库都是partition，极端就是每个用户的数据是一个partition，简单的增加
机器就能处理高峰 |
|
s*****r
发帖数: 43070 | 42 big table不支持transaction，应该是类似spanner的数据库 |
|
|
|
发帖数: 1 | 45 你是说到点子了，一个用户是一个partition，性能最好，无人可比
但是其他人没法这么做，因为用户之间可能有关联，比如火车订票。
但是淘宝商家之间没关联，所以它愿意创造世界纪录，是很容易的 |
|
s*****r
发帖数: 43070 | 46 火车票对超售是零容忍，还有座位分配的要求，高并发下难度比淘宝天猫高多了 |
|
s*****r
发帖数: 43070 | 47 火车票的数据模型比零售业难太多了，内部逻辑非常复杂
天猫无非就是用户数据做最极端的partition，就是所有相关数据都放在一起，降低
transaction的复杂度和执行时间，剩下就是堆机器 |
|
s***h
发帖数: 487 | 48 Google 用 Big Table 本身，并不能说明 Big Table 一定比 Apache Cassandra 或
Postgres 技术上更合适。
Google 的架构最海量没错。但 Google 也受制于自己的 20 年 legacy system，新架
构要兼容过去，也是个负担。
: 是不是知道MySQL就感觉牛大了？这是幻觉:-)
: 你从哪里听说YouTube用mysql？Google还在用MySQL吗？人自家的big table，
spanner
: 都出来多久了https://ai.google/research/pubs/pub39966, https://en.
wikipedia.
: org/wiki/Spanner_(database))。
|
|
s***h
发帖数: 487 | 49 可以在 big table 上面做一层 transaction。但缺点就是费程序猿人工，不是标准化
将来也不容易重用。
当然国内人肉电池价格便宜量又足是优势。许多国内能做的，美帝不一定能做。
: big table不支持transaction，应该是类似spanner的数据库
|
|
s*****r
发帖数: 43070 | 50 big table的优势是非transaction的海量读写，海量transaction就是spanner，狗家发
明的技术，没毛病 |
|
