在线观看不卡亚洲电影_亚洲妓女99综合网_91青青青亚洲娱乐在线观看_日韩无码高清综合久久

Install
Package Control
This is the easiest way to install the plugin.

Follow these instructions to install Package Control.
Package Control: Install Package
Look for Apache Hive in the packages list
Manual - Git
Locate your Packages directory in Sublime Text (for instance Preferences > Browse Packages ...).

Clone the repository in this directory

git clone https://github.com/glinmac/hi... "Apache Hive"

https://github.com/glinmac/hi...

應(yīng)該是路徑?jīng)]有引入吧，mac中的例子

你把 servlet 的 method 與 HTML form 的 method（即 HTTP method） 混淆了，它們并沒有直接的關(guān)系。
而且 HTML form 的 method 屬性值只能是 get 或 post。

要實(shí)現(xiàn)自定義 HTTP method "LOGIN"，你要在 servlet 添加處理 HTTP LOGIN method 的邏輯，如

// 重寫 HttpServlet.service() 以支持自定義 HTTP method。
package demo;

import javax.servlet.http.HttpServlet;

class CustomHttpServlet extends HttpServlet {
    protected void service(HttpServletRequest req, HttpServletResponse resp) {
        if (req.getMethod().toLowerCase() == "login") {
            this.doLogin(req, res);
            return;
        }
        super.service(req, resp);
    }

    protected void doLogin(HttpServletRequest req, HttpServletResponse resp) {
        // 與 doGet() 類似，在此處添加處理邏輯。
    }
}

這時(shí)不能使用 HTML form 測試，應(yīng)該使用接口測試工具，發(fā)送類似下面的請求

LOGIN  http://127.0.0.1:8080/xxx

譬如

curl -X LOGIN  http://127.0.0.1:8080/xxx

<=2.2.x的驅(qū)動這樣寫沒有問題。如果你沒有給具體版本號，現(xiàn)在會安裝3.0驅(qū)動，API已經(jīng)變化了。你可以

1. 如果沒有準(zhǔn)備好升級，降級到到2.2驅(qū)動，修改package.json并重新npm install。
2. 使用3.0驅(qū)動，并相應(yīng)修改代碼。樓上所述是正確的，也可以參考文檔：http://mongodb.github.io/node...

map方法返回的是一個(gè)新數(shù)組，不會改變原來的數(shù)組

this.opts = [1,2];
let result = this.opts.map(item => item*12)
console.log(result)

可以
把表名作為參數(shù)

這幾個(gè)字段都很小, 如果查詢條件相對固定的話,可以把這幾個(gè)字自段連一塊,形成一個(gè)字個(gè)段, 或物化視圖,并對此字段建索引. 然后只需查一個(gè)字段即可.

還有就是userid!=xxx, 最好改成(userid>xxx and userid<xxx), 也許我的經(jīng)驗(yàn)過時(shí)了, 但至少值得一試.

這個(gè)和mysql沒有關(guān)系吧，就是python代碼在運(yùn)行的時(shí)候記錄插入位置就行了呀

你說的是建表的字段么？我是在跨境電商公司上班，分享一下公司的商品表中的基本字段。
sku，商品的唯一標(biāo)識，如一件白色的T恤
spu，同款sku的組合，如同款的T恤，有白色，藍(lán)色，黃色，紅色等
scu，多個(gè)sku的組合，如上衣和褲子一起賣
scpu，同款scu的組合，
price，長描述，短描述（買點(diǎn)），可用庫存，倉庫號，銷售員，采購員，商品類名，商品圖片，
商品狀態(tài)（上架，下架，待發(fā)貨，待顧客反饋，待質(zhì)檢，等等一大堆）
還有好多，，，，數(shù)據(jù)庫用的是Mongodb，淘寶好像用的是Mysql，用的是他們自己家開發(fā)的Druid 鏈接數(shù)據(jù)庫。
所有表都應(yīng)該有的，id，創(chuàng)建時(shí)間，更新時(shí)間，就不多說了。

謝邀。
這個(gè)select count(*) from md_org 只是個(gè)查詢，和鎖沒有關(guān)系，沒有被鎖。

Rows:26553 是個(gè)粗略的統(tǒng)計(jì)數(shù)據(jù)，并不保證準(zhǔn)確，具體的行數(shù)使用selct count(xxx)獲得。

如果查出來為0，就表示表中實(shí)際行數(shù)就是0了。

你的這種情況我還原下：
你開啟事務(wù)，然后不停的插入數(shù)據(jù)，插入2萬多條的數(shù)據(jù)，這個(gè)時(shí)候show table status中的rows 就看到你插入的2萬多條數(shù)據(jù)，但是你不小心關(guān)掉了x掉了窗口，導(dǎo)致事務(wù)沒有提交，實(shí)際表中是沒有這些數(shù)據(jù)的（mysql 不會很智能的更新rows的條數(shù)，它只是一個(gè)粗略的統(tǒng)計(jì)而已，沒有必要）。

1. 環(huán)境變量問題，可以先source一下
2. 命令行使用絕對路徑

select date, count('字段') as '顯示的名字' , count('字段') as '顯示的名字' from `表` group by date

//date 表示 日期的字段名

JdbcTemplate在IDEA下使用的時(shí)候，有對SQL語法校驗(yàn)的功能.

手寫語句+注解，mysql Innodb 自己會加行級鎖，保證下面的語句線程安全，當(dāng)然 前提是你的 id 有索引

@Modifying
@Query("update products sc set quantity = quantity -1 where sc.id = ?")
public void UpdateById(@Param(value = "ids") String id);

&dollar;map,&dollar;reduce,&dollar;filter (segmentfault無法正確轉(zhuǎn)義美元符號，湊合看吧……)這些運(yùn)算符在很多場景下可以幫助我們避免$unwind，語法請參考下文檔。對于你的要求，可以用$filter直接解決問題：
文檔格式：

{
    "_id" : ObjectId("5a6d7c5e0664b8343e7e126b"),
    "keyID" : "111111111111",
    "price" : 123,
    "remark" : [
        {
            "city" : "beijing",
            "point" : "A"
        },
        {
            "city" : "shanghai",
            "point" : "A"
        },
        {
            "city" : "guangzhou",
            "point" : "C"
        }
    ]
}

aggregation寫法：

db.test.aggregate([{
    $match: {
        "remark.point": "A"
    }
}, {
    $project: {
        _id: 1,
        keyID: 1,
        price: 1,
        remark: {
            $filter: {
                input: "$remark",
                as: "remarks",
                cond: {
                    $eq: ["$$remarks.point", "A"]
                }
            }
        }
    }
}])

({login, loading})=>({}) 這是一個(gè)函數(shù),和connect 函數(shù)的兩個(gè)參數(shù)不同,我應(yīng)該如何理解這個(gè)寫法?

這是使用的第一個(gè)函數(shù)mapStateToProps（state, ownProps） ps: 兩個(gè)參數(shù)相對應(yīng)。
   login：這個(gè)參數(shù)就是[models/login.js]里面，[reducers/changeLoginStatus]的返回值。
   

login和submitting這個(gè)怎么理解,是指綁定到submitting到組件的this.props里面嗎?

按資料說法，這兩個(gè)都是要加到this.props上面的對象。 

那么他是如何把src/models/login.js 里面的effects觸發(fā)的?

[models/login.js]，應(yīng)該在聲明路由[common/router.js]的時(shí)候就已經(jīng)指定，
   觸發(fā)應(yīng)該是用的[ruotes/User/Login.js]的[handleSubmit]

并且在組件中沒有看到如何方法調(diào)用submitting.

調(diào)用應(yīng)該是指這里[ruotes/User/Login.js]的[render]

loading.effects['login/login'] 這個(gè)方法應(yīng)該如何理解?

這個(gè)就是猜測了，應(yīng)該是返回的[model/login.js]下面[*login]的執(zhí)行狀態(tài)，bool值。

建議單獨(dú)創(chuàng)建表保存最近聯(lián)系人。
1、從功能設(shè)計(jì)上看，最近聯(lián)系人是個(gè)獨(dú)立的功能，不依賴于聊天記錄，這一點(diǎn)你已經(jīng)說過了。
2、從系統(tǒng)性能方面考慮，每次從聊天日志表從計(jì)算最近聯(lián)系人，數(shù)據(jù)量大的時(shí)候會存在性能瓶頸。

你說的思路比較亂，先聚焦一下問題：

如果是持續(xù)的寫入壓力大，且超過單臺服務(wù)器磁盤IO寫入能力，最簡單的辦法就是mysql分為多個(gè)數(shù)據(jù)庫，保證數(shù)據(jù)能分布不同的磁盤設(shè)備上，以提升寫入的能力。

如果只是高峰期的寫入壓力大，可以考慮讀寫主要靠緩存的方案，后臺同步到數(shù)據(jù)庫，但這樣對緩存的可用性、數(shù)據(jù)預(yù)熱方面的要求較高。

java方面的優(yōu)化，主要是提高接入能力，和后端數(shù)據(jù)庫是否能支持大數(shù)據(jù)寫入沒關(guān)系。

題外話，MongoDB歷史上出現(xiàn)過master/slave復(fù)制（其實(shí)現(xiàn)在也還存在）。嚴(yán)格地說，主備通常指的是那個(gè)東西。而我們現(xiàn)在用的基本上是復(fù)制集（replica set）。

再說你這種情況，其實(shí)是正常的。原理跟你的磁盤用久了會有碎片是一個(gè)道理。特別是你曾經(jīng)大規(guī)模刪除過數(shù)據(jù)的情況下。簡單地解釋下，假設(shè)你的表中有doc1/doc2/doc3/doc4一共4個(gè)文檔，在磁盤上的存儲順序是：
doc1|doc2|doc3|doc4
現(xiàn)在你刪除了doc2，磁盤上的空間使用情況變成：
doc1|(空白)|doc3|doc4
系統(tǒng)是沒有辦法釋放這個(gè)空白空間的，除非你進(jìn)行磁盤整理，把空白空間移到最后：
doc1|doc3|doc4|(空白)
然后系統(tǒng)才可以截?cái)辔募膊康目瞻?，釋放掉這個(gè)空間?？梢钥闯鰜恚芽瞻滓苿拥轿募彩莻€(gè)相當(dāng)費(fèi)時(shí)費(fèi)力的操作，最簡單的辦法是：把后面所有的文檔順序前移來填補(bǔ)doc2留下的空白（如上所示doc3/doc4被前移）。但是這樣涉及到大量的磁盤I/O，會對性能造成嚴(yán)重影響。當(dāng)然不乏其他整理磁盤碎片的方法，但是無論哪一個(gè)，都會造成比較嚴(yán)重的I/O影響，因此一般我們是不會進(jìn)行這樣的整理的。進(jìn)行碎片整理的方式就是：compact命令。如前所述，因?yàn)樗鼤π阅茉斐蓢?yán)重的影響，因此一般只會在維護(hù)時(shí)間進(jìn)行這個(gè)操作。而就算你不進(jìn)行這個(gè)操作，系統(tǒng)也知道哪些地方是空白的，在有新文檔進(jìn)來的時(shí)候，會嘗試重新使用這些空白的部分從而最大化空間利用率。只是，無論再好的算法，空間重復(fù)利用一定不可能是100%的，因?yàn)樾逻M(jìn)來的文檔永遠(yuǎn)沒有辦法正好跟之前被刪除的文檔一樣大，所以只能找一個(gè)比新文檔更大的空間來利用，這樣就會留下一個(gè)更小的、更難重復(fù)利用的碎片。
另外一種變通的方案是把節(jié)點(diǎn)內(nèi)容刪除，重新進(jìn)行一次同步。因?yàn)橥綍r(shí)相當(dāng)于把所有文檔全部抓取一遍，并一個(gè)接一個(gè)重新寫到磁盤上，因此同步完成之后文檔在磁盤上是緊湊排列的，相當(dāng)于進(jìn)行了碎片整理。而且在這個(gè)過程中，受影響的是從節(jié)點(diǎn)，它在同步過程中并不對外提供服務(wù)，所以對線上的影響是最小的。但是注意，它同樣會對主節(jié)點(diǎn)造成影響，因?yàn)樗阎鞴?jié)點(diǎn)上的全部數(shù)據(jù)都讀一遍，主節(jié)點(diǎn)I/O升高是無法避免的。

最后回到你的問題，為什么從節(jié)點(diǎn)比主節(jié)點(diǎn)小，上面應(yīng)該已經(jīng)解釋清楚了。

在 sql 下, 方案2更好. 在 mongo 下, 方案1更好.
不知道你的這個(gè)項(xiàng)目中有沒有用戶權(quán)限組的概念.
如果有權(quán)限組的話, 就是一個(gè)權(quán)限組的 collection 里面, 每個(gè)權(quán)限下保存了一個(gè)菜單項(xiàng)的數(shù)組.
如果沒有權(quán)限組的話, 就可以按照你說的方案1, 在每個(gè)用戶表里, 或者單獨(dú)的用戶權(quán)限表里, 保存一個(gè)菜單數(shù)組.
當(dāng)然, 保存菜單項(xiàng)的 id 數(shù)組或許更合適.

mongo 里面數(shù)組也是可以建立索引的, 查詢也很方便.
另外, 也可以參考 mongo 自身的權(quán)限系統(tǒng), 其權(quán)限設(shè)置也是保存在 mongo 數(shù)據(jù)庫內(nèi)的, 通常都是 admin 庫下的 users 表. 如果你的 mongo 開啟了權(quán)限管理, 并且權(quán)限庫名字就叫 admin, 則可以用以下命令查看:

> use admin
switched to db admin
> show users
{
    "_id" : "admin.admin",
    "user" : "admin",
    "db" : "admin",
    "roles" : [
        {
            "role" : "root",
            "db" : "admin"
        }
    ]
}
{
    "_id" : "admin.migration",
    "user" : "migration",
    "db" : "admin",
    "roles" : [
        {
            "role" : "backup",
            "db" : "admin"
        },
        {
            "role" : "read",
            "db" : "local"
        },
        {
            "role" : "read",
            "db" : "some_database"
        }
    ]
}
{
    "_id" : "admin.sys",
    "user" : "sys",
    "db" : "admin",
    "roles" : [
        {
            "role" : "__system",
            "db" : "admin"
        }
    ]
}

以上輸出為示例. 可以看到官方存儲權(quán)限的方案也是用數(shù)組.

參考:
mongo 官方文檔 - 用戶權(quán)限管理
mongo 官方文檔 - 數(shù)組索引