|
|
|
g****n
发帖数: 3313 | 4 BTREE 2 天就把我跟某ID要了1年的PHP+DUPAL+ MYSQL 的东西做好了。。。。。。。真
的佩服死了。。。。 |
|
|
x***m
发帖数: 1733 | 6 btree de case probably $40 50w for two. same as 1M $300? |
|
|
|
|
|
o**********e
发帖数: 18403 | 11 有人说为什么老中不去STARTUP，
那里烙印不多。 我的解释如下：
STARTUP 十个中八九个默默无闻。
员工苦逼的干苦工的，永远也是
FOOT SOLDIER的大概也这个RATIO。
烙印估计不屑于这种苦力活，所以
把这个机会让给老中老美。
烙印呢，就吹吹牛皮，造假简历，
拉拉种姓关系，IT界无数个烙印山头，
哪一个不是30-70%烙印管理，足够
排挤任何一个不服气的老中老美，
抢任何一个能干的老中老美的功劳／好项目，
扼杀任何别人的项目。
VMWARE，MICROSOFT，CISCO，QUALCOMM，
ADOBE，NOKIA， IBM，MOTOROLA
无数IT部门：JPM CHASE， BOA， TARGET，
HOMEDEPOT， HEALTHCARE.GOV
有了CRITICAL MASS，
然后几个BTREE往上供出一个洁白芬芳
圣洁无比的婆罗门去做CEO，像萨提亚
那样的。 鼓吹着神圣的KARMA，砍
18000员工，同时给1亿刀IT PROJECT
给INFOSYS。 让INFOSYS做DISCRIMINATION
的DIRTY WORK。
然后再拿钱去投资他们... 阅读全帖 |
|
o**********e
发帖数: 18403 | 12 【 以下文字转载自 JobHunting 讨论区 】
发信人: SYSDP (SYSOP), 信区: JobHunting
标 题: 感觉被老板歧视了而且还想让我背黑锅怎么办？ (转载)
发信站: BBS 未名空间站 (Sat Nov 21 00:47:13 2015, 美东)
发信人: SYSDP (SYSOP), 信区: Working
标 题: 感觉被老板歧视了而且还想让我背黑锅怎么办？
发信站: BBS 未名空间站 (Sat Nov 21 00:26:15 2015, 美东)
我们组一个年轻的白人4级软工，一个年老的白人4级软工，一个年轻的白人3级软工，
我、烙印、巴西人自称是棕色人种的是2级软工，一个黑人小弟是1级软工，另外还有一
个offshore的烙印是contractor
我们用的一个收费的ETL软件由于授权费太高，准备换便宜的，但是上层领导不知怎么
搞的，就是不让我们自己重写in house的homegrown程序。去年最后一个季度那个年轻
的白人4级软工找了个便宜的，老板一路游说上去批了替换成这个便宜的。两个白人4级
软工去年就开始用这个便宜的开始重写以前的ET... 阅读全帖 |
|
o**********e
发帖数: 18403 | 13 【 以下文字转载自 SanFrancisco 讨论区 】
发信人: onetiemyshoe (onetiemyshoe), 信区: SanFrancisco
标 题: 感觉被老板歧视了而且还想让我背黑锅怎么办？ (转载)
发信站: BBS 未名空间站 (Sun Nov 22 10:32:43 2015, 美东)
发信人: SYSDP (SYSOP), 信区: JobHunting
标 题: 感觉被老板歧视了而且还想让我背黑锅怎么办？ (转载)
发信站: BBS 未名空间站 (Sat Nov 21 00:47:13 2015, 美东)
发信人: SYSDP (SYSOP), 信区: Working
标 题: 感觉被老板歧视了而且还想让我背黑锅怎么办？
发信站: BBS 未名空间站 (Sat Nov 21 00:26:15 2015, 美东)
我们组一个年轻的白人4级软工，一个年老的白人4级软工，一个年轻的白人3级软工，
我、烙印、巴西人自称是棕色人种的是2级软工，一个黑人小弟是1级软工，另外还有一
个offshore的烙印是contractor
我们用的一个收费的ETL软件由于授... 阅读全帖 |
|
|
v****s
发帖数: 1112 | 15 除了index,还有什么可以优化的么?
我试过了btree, hash，都没有显著提高 |
|
v****s
发帖数: 1112 | 16 谢谢各位！这是create table statement, 请帮忙看看如何提高select 的速度。
我只用这个语句：
select * from shortest where ((p1=x and p2=y) or (p1=y and p2=y))
delimiter $$
CREATE TABLE `shortest` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`p1` varchar(45) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL DEFAULT
'',
`p2` varchar(45) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL DEFAULT
'',
`dist` varchar(45) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL
DEFAULT '',
PRIMARY KEY (`id`),
KEY `p1p2` (`p1`,`p... 阅读全帖 |
|
v****s
发帖数: 1112 | 17 because there is no index for intVal in my case! the index btree is built
ontop of varchar type.
but i don't know how mysql recognize this type error and convert it secretly
. that's why it took 3 sec,
converting int to varchar |
|
z***y
发帖数: 7151 | 18 在SQL Server 里， null 值在btree 里当然是有的。 但是不是值本身。 是标识nulll
的bitmap。 |
|
z***y
发帖数: 7151 | 19 在SQL Server 里， null 值在btree 里当然是有的。 但是不是值本身。 是标识nulll
的bitmap。 |
|
c*****d
发帖数: 6045 | 20 第一，如果每个index都只能建在单个column上
index_1 shows last_name='xxx'的记录有第1，3，5，7，9行
index_2 shows email='yyy'的记录有第3，5行
这两个如果是btree index没法做交集操作
bitmap index可以
第二，这个问题想解决请google composite index |
|
c*****d
发帖数: 6045 | 21 第一点，当然可以创建bitmap然后and/or操作。但是bitmap和btree index存储方式完
全不同，并不是所有的字段都适合bitmap。你这两个字段都不适合bitmap
第二点，“composite index一般不index单个column，浪费很大”不知道你在说什么。
composite index本来就是在两个字段上作index
cost |
|
c*****d
发帖数: 6045 | 22 bitmap不是一种join方式，他只是一种索引，只不过支持and/or/not
query planner会根据具体索引结构建立最佳方案，选择最佳的一个index
但是，你没办法让两个btree index作and/or/not
在你这个例子中，可以创建单独last name字段的索引，或者email上的索引，或者(
last_name,email) or (email, last_name)上建立composite index，如果你创建了这
些索引，当然storage上是浪费了，但是提高了查询效率。我们很多表都是5-10个索引
INDEX |
|
w*r
发帖数: 2421 | 23 Most rdbms like oracle db2 SQL server optimizer is designed in the way to
shorten the io path cost to accommodate oltp. oracle index join hint will
bring both index into consideration. Bitmap index provided a faster
operation using and/or operation on the single index, however I doubt it
will benefit index join performance . Bitmap index probably more cost
effective when the distinct values in the index is low.
For low cardinality columns , partition is a better choice comparing to
index in mos... 阅读全帖 |
|
z*f
发帖数: 293 | 24 一个人问给一个20 PAGES的文章，和一个20000-30000TERM的字典，你怎么找出
字典里面每个词在文章的HIT，并MARK出来
我说LOAD 字典到MEMORY 建立HASHTABLE 或者BTREE，然后文章的词一个一个查
他好像不是很满意，请问还有什么方法吗？
反过来？
谢谢 |
|
v****s
发帖数: 1112 | 25 i tried, but there is no significant improvement, still takes about 1 sec
per
query.
i used hashtable, maybe i should use btree? |
|
d****n
发帖数: 1637 | 26 用Btree吧，连续的就删掉。
其他做法，我估计要用memory pool library. |
|
n*****t
发帖数: 22014 | 27 鸭就是个半瓶醋，DB 做了 index 后，select 就是用的 btree 或者 hash，拌醋非得
画蛇添足再加个字段存 hash key。其实我故意一开始没告诉鸭，就看鸭的下限究竟是
多少。
说鸭拌醋真是侮辱醋了，我向无辜的醋表示道歉 |
|
d******e
发帖数: 2265 | 28 你要找poi活着user,肯定是在后端做了。
那么，最简单的scan，计算，就是你说的o(n).
这对uber这样的级别数据库是不可行的。
其次，rtree range query. postgre gis 支持。但是这个不可scalable.
在其次， kd tree, k维还是太复杂。
geohash将为一维,这个可以用btree index了。甚至可以做成hash+trie，纯内存结构。
update, query 都是常数到o(log(n)) + o(t)级别的操作。t在bounding box里面的用
户数目。
geohash本质就是经纬度变成01然后base 36编码。 |
|
w***g
发帖数: 5958 | 29 btree是磁盘数据结构，如果是内存操作，就是overengineer了，不如红黑树。数据结
构问题貌似和服务器架构没啥关系。
solution |
|
S*******B
发帖数: 14 | 30 【 以下文字转载自 JobHunting 讨论区 】
发信人: ShowMeRMB (ShowMeRMB), 信区: JobHunting
标 题: 码工找工经验1-转行篇-当断则断
发信站: BBS 未名空间站 (Sun Jun 24 00:51:52 2012, 美东)
刚拿到一份心仪已久的工作， 这次找工算告一段落。以往每次找工作，都从版上获得
了很多宝贵的信息，但是过去一直很懒，主要潜水，这次正好利用空闲时间，把自己的
几次找工的经历加以整理总结，算是回馈一下版面，也希望对版上诸位朋友有所帮助。
在这系列文章里，我尽量不谈具体公司的面试题，一个原因是签了协议, 另一个原因
是已有的资料已经很全面。 career cup, leetcode, glassdoor, 和本版题目包罗了
市面上绝大部分技术类题目。本来我想做一个总结面试题的网站，后来发现leetcode
已经在那儿了，而且比我想做的还要好，遂作罢。我会把我的一点的练习编程和准备技
术面试的要点整理以后换一种方式来给大家分享。
用马甲发贴是想主id以后还可以去各版随心所欲胡喷，也希望生活中认识的朋友不要点
破。
我... 阅读全帖 |
|
