小编Sim*_*ini的帖子

我在 python3.4.3 上使用 SqlAlchemy 来管理 MySQL 数据库。我正在创建一个表：

from datetime import datetime

from sqlalchemy import Column, text, create_engine
from sqlalchemy.types import TIMESTAMP
from sqlalchemy.dialects.mysql import BIGINT
from sqlalchemy.ext.declarative import declarative_base

Base = declarative_base()
class MyClass(Base):

  __tablename__ = 'my_class'

  id = Column(BIGINT(unsigned=True), primary_key=True)
  created_at = Column(TIMESTAMP, default=datetime.utcnow, nullable=False)
  updated_at = Column(TIMESTAMP, default=datetime.utcnow, onupdate=datetime.utcnow, nullable=False)
  param1 = Column(BIGINT(unsigned=True), server_default=text('0'), nullable=False)

当我创建这个表时：

engine = create_engine('{dialect}://{user}:{password}@{host}/{name}'.format(**utils.config['db']))
Base.metadata.create_all(engine)

我得到：

mysql> describe my_class;
+----------------+---------------------+------+-----+---------------------+-----------------------------+
| Field          | Type                | Null | Key | Default             | Extra                       | …

我正在使用PHP的bcmath库来执行定点数的操作.我期望获得Python Decimal类的相同行为,但我很惊讶地发现以下行为:

// PHP:
$a = bcdiv('15.80', '483.49870000', 26);
$b = bcmul($a, '483.49870000', 26);
echo $b;  // prints 15.79999999999999999999991853

Decimal在Python中使用s我得到:

# Python:
from decimal import Decimal
a = Decimal('15.80') / Decimal('483.49870000')
b = a * Decimal('483.49870000')
print(b)  # prints 15.80000000000000000000000000

这是为什么？当我使用它来执行非常敏感的操作时,我想找到一种方法来在PHP中获得与Python相同的结果(即(x / y) * y == x)

我在python中使用igraph库.我想知道是否有一种使用字符串作为顶点索引的方法.我知道'name'属性,我可以写

g = igraph.Graph(directed=True)
g.add_vertex('hello')
g.add_vertex('world')
g.add_edge('hello','world')

一切正常.除非我添加两次相同的顶点,例如:

g = igraph.Graph(directed=True)
g.add_vertex('world')
g.add_vertex('hello')
g.add_vertex('hello')

创建了两个不同的顶点,如果我现在添加一个边:

g.add_edge('hello','world')

边缘被添加到匹配'hello'的第一个顶点作为名称.这也表明这种形式的索引具有O(n)复杂度而不是O(1)(即,扫描整个顶点列表直到v['name'] == 'hello'找到顶点v ).

所以我在考虑保持顶点名称和索引之间的映射,例如:

mapping = {}
g = igraph.Graph(directed=True)
g.add_vertex('hello')
mapping['hello'] = len(g.vs)-1
g.add_vertex('world')
mapping['world'] = len(g.vs)-1
g.add_edge(mapping['hello'],mapping['world'])

我认为这应该工作,因为我从不删除顶点,所以我猜索引应该保持不变.它还具有用于查找的平均速度O(1),其应该比先前的解决方案更好.不过我想知道:

• 我总能保证g.vs[i].index == i吗？(也就是说,我总是可以使用vs数组中顶点的位置来引用像add_edge()？这样的函数中的顶点)
• 我总是保证当我向图表中添加一个新的顶点时,它的索引会是len(g.vs)-1什么？

编辑:关于边缘的相同问题:我保证我会找到最后添加的边缘g.es[len(g.es)-1]吗？

考虑以下代码（解释如下）：

import asyncio

class MyClass(object):
    def __init__(self):
        self.a = 0
    def incr(self, data):
        self.a += 1
        print(self.a)

class GenProtocol(asyncio.SubprocessProtocol):
    def __init__(self, handler, exit_future):
        self.exit_future = exit_future
        self.handler = handler

    def pipe_data_received(self, fd, data):
        if fd == 1:
            self.handler(data)
        else:
            print('An error occurred')

    def process_exited(self):
        self.exit_future.set_result(True)

def start_proc(stdout_handler, *command):
    loop = asyncio.get_event_loop()
    exit_f = asyncio.Future(loop=loop)
    subpr = loop.subprocess_exec(lambda: GenProtocol(stdout_handler, exit_f),
                                 *command,
                                 stdin=None)
    transport, protocol = loop.run_until_complete(subpr)

    @asyncio.coroutine
    def waiter(exit_future):
        yield from exit_future

    return waiter, exit_f

def main():
    my_instance = MyClass()
    loop …

我有以下配置：

• 一台运行三个 docker 容器的主机：
  • MongoDB
  • Redis
  • 使用前两个容器存储数据的程序

Redis 和 Mongodb 都用于存储海量数据。我知道 Redis 需要将所有数据保存在 RAM 中，我对此没有意见。不幸的是，Mongo 开始占用大量 RAM，一旦主机 RAM 已满（我们在这里谈论的是 32GB），Mongo 或 Redis 就会崩溃。

我已经阅读了以下有关此问题的先前问题：

1. 限制 MongoDB RAM 使用：显然大部分 RAM 已被 WiredTiger 缓存占用
2. MongoDB 限制内存：这里显然问题是日志数据
3. 限制 MongoDB 中的 RAM 内存使用：这里他们建议限制 mongo 的内存，以便它使用较少的内存来缓存/日志/数据
4. MongoDB 使用太多内存：这里他们说它是 WiredTiger 缓存系统，它倾向于使用尽可能多的 RAM 来提供更快的访问。他们还表示it's completely okay to limit the WiredTiger cache size, since it handles I/O operations pretty efficiently
5. 有没有限制mongodb内存使用的选项？: 再次缓存，他们还添加MongoDB uses the LRU (Least Recently Used) cache algorithm to …