Google AppEngine

sliuhao

有人对Google AppEngine有什么看法么?今天突然对这个有点兴趣..

tristone

原帖由 sliuhao 于 22-6-2011 12:29 发表

                               
登录/注册后可看大图

有人对Google AppEngine有什么看法么?今天突然对这个有点兴趣..

只是听说。。。



最大的缺点：被封了，墙内别用。
另外一个缺点：只能用google的语言（据说类python），google的数据库（不是关系数据库，不用SQL）


优点：流量/CPU不大不要钱，google的云技术，稳定

sliuhao

我个人感觉这个是个借鸡生蛋的好地方....

ljbit

本人曾经用一段时间。
1. 开发语言目前支持2种，包括Java和Python。我自己比较钟爱Python，在被墙之前曾经写过几个web service，跟手机上的客户端交互的，觉得很有意思，体验到了云计算的威力，呵呵
2. Google提供了模拟器可以部署到本机运行的，方便调试，部署到Google的服务器后还能够通过console看日志，检查数据库，使用分析什么的都有，赞！
3. 免费的个人用户可以创建5个还是10个应用，流量什么的也有一定的限制，花钱的商业用户限制会少一些
4. 数据库方面是基于GQL的非关系数据库，效率方面是没有问题的，给免费用户的空间应该也是足够的
5. 2年以前还处于Beta时好像不太稳定，我曾经碰到过宕机的情况发生，而且不止一次。正式release之后呢。。。。。。就被墙掉了。据说是因为有人用GAE写web service专用于翻蔷，惹恼了GFW
6. 好像有些借鉴Apple  AppStore的模式，也有web应用的store，貌似没有水果店那么火，个人感觉对企业用户更有用吧

[ 本帖最后由 ljbit 于 22-6-2011 20:13 编辑 ]

ubuntuhk

我感觉GAE的限制太大了，如果不是用Java和Python，就没法用了，所以我也一直没关注过GAE呢。

还是Amazon的EC2云计算更亲民一些，可以当作Linux虚拟机来用，灵活很多。

sliuhao

恰好我是做java和python的， 越看越对眼...
1) 04年我看到jgroup的时候，就想如果能做一种系统架构能够支持这种以后所谓叫“云”计算能力，就可以卖给中小企业，也就是他们省去了建立和维护数据中心的费用
2）仅支持java/python也没有什么不妥， 但是如果数据库API这些不兼容，原来应用移植到GAE就不是透明的.google为什么不尝试在GAE上用底层自己的分布式数据库去实现RDBMS的接口， 这样，现在在跑的java应用说不定就可以直接移植;再或者用类python去实现JDK.........
3) 我觉得GAE是一个能用最少投资，能最大实现全球部署和发布应用的平台，如果你有一个好主意，不妨就可以借助于GAE

google放弃GAE不妨是一个好事（但没有关闭），这样大家就可以想怎么玩就怎么玩了。

tristone

原帖由 sliuhao 于 23-6-2011 20:41 发表

                               
登录/注册后可看大图

oogle为什么不尝试在GAE上用底层自己的分布式数据库去实现RDBMS的接口 ...

我觉得google不会这么做，因为RDBMS没有什么前途的。为了保证事务的完整性，关系数据库牺牲了太多的性能来加锁解锁，性能差，scalability也差。就是因为这个原因我所在的公司没有用Oracle，而是用Sybase。近几年技术的发展有并行化、功能化的趋势。

有个叫Arthur Whitney的牛人写了个K语言，大投行都在用。这个语言NB的地方在于性能奇高，几亿条数据甚至几十亿条数据，可以实时做aggregation，比方说每秒钟做几次或者几十次average，sum之类的运算。我们培训的时候，instructor说，在k语言里，没有线程，不用同步，所以才快。他甚至说，多线程是一个过时的技术，几年以后，大家都会忙着学k语言这样的functional programming。

当时以为他的话多少带点吹牛的成分，现在才发现，整个世界确实都在搞这个。NVidia在搞OpenCL，微软在搞C++ AMP。。。

sliuhao

原帖由 tristone 于 24-6-2011 15:19 发表

                               
登录/注册后可看大图

我觉得google不会这么做，因为RDBMS没有什么前途的。为了保证事务的完整性，关系数据库牺牲了太多的性能来加锁解锁，性能差，scalability也差。就是因为这个原因我所在的公司没有用Oracle，而是用Sybase。近几年 ...

你认为这个趋势会到一般应用一层么？ 也就说可能现在的东西都要重写？

tristone

原帖由 sliuhao 于 24-6-2011 15:26 发表

                               
登录/注册后可看大图

你认为这个趋势会到一般应用一层么？ 也就说可能现在的东西都要重写？

我觉得最终会的，不过需要一个很长的过程，就像现在很多银行都还在用COBOL一样。重写不重写，应该是case by case的。

。。。
顺便问一下，你知道python的dictionary为啥那么慢么？好像是用类似链表而不是二叉树或者哈希表实现的，数据少的时候不觉得，但是有一次我插入大约20万条数据，花了5分钟以上时间。

sliuhao

顺便问一下，你知道python的dictionary为啥那么慢么？好像是用类似链表而不是二叉树或者哈希表实现的，数据少的时候不觉得，但是有一次我插入大约20万条数据，花了5分钟以上时间。

sorry, 我没有你那么大的数据需求：200，000/300=666 per sec. 平均1毫秒多一个数据....

sliuhao

对了， K能被方便的集成么？

值班管理员001

原帖由 tristone 于 24-6-2011 15:19 发表

                               
登录/注册后可看大图

有个叫Arthur Whitney的牛人写了个K语言，大投行都在用。这个语言NB的地方在于性能奇高，几亿条数据甚至几十亿条数据，可以实时做aggregation，比方说每秒钟做几次或者几十次average，sum之类的运算。我们培训的时候，instructor说，在k语言里，没有线程，不用同步，所以才快。他甚至说，多线程是一个过时的技术，几年以后，大家都会忙着学k语言这样的functional programming。

好像是Q语言和Kdb?

sliuhao

http://www.cs.nyu.edu/courses/fall02/G22.3033-007/kintro.html

Conclusion

K and KDB have three advantages over other database and language environments:
expressive (time series, large data, math)
fast
(as a consequence) no need to interface several different languages
K is best suited to mathematical sophisticates.
KDB is a library in K and can be learned by anyone familiar with SQL, though K expertise is necessary too.
K and KDB can interact with classical database management systems, e.g. Sybase, Oracle, etc. via ODBC or special purpose interfaces (such as Oracle's array facility).
Other programming systems (Java, Visual Basic, Web browsers) can call K and KDB via interprocess communication or through sockets

[ 本帖最后由 sliuhao 于 24-6-2011 15:56 编辑 ]

tristone

原帖由 值班技术员 于 24-6-2011 15:54 发表

                               
登录/注册后可看大图

好像是Q语言和Kdb?

最早是K语言，从A语言发展而来。A难得不可致信，因为符号之多，需要特制的键盘。Arthur在A的基础上简化，写出了K语言。

但是K仍然太难，于是进一步简化，成为投行程序员能够学会的Q语言。

Q仍然很难，以至于Jeff Borror（给我们上课的那位老兄）写的书名字叫《Q for Mortals》