Abstract: Data streaming applications may need to provide high reliability, particularly depending on the nature of the data being streamed. A framework is described that allows a data streaming application to ensure high reliability both during update operations and during ordinary operations. A unique event ID count can be recorded that reflects messages being sent from a source to the streaming application. After an update and service restart, the count can again be collected to see if data is flowing through the streaming application as expected. Unique database record counts can be reviewed (e.g. after a restart or during ordinary operations) to ensure that no records are being unexpectedly dropped. Data content sampling can also be performed to see that any data transformations are functioning properly. Corrective actions (after a restart or during ordinary operations) can also be taken, including replay of database messages that are dropped, or sending an alert.

Abstract: Data streaming applications may need to provide high reliability, particularly depending on the nature of the data being streamed. A framework is described that allows a data streaming application to ensure high reliability both during update operations and during ordinary operations. A unique event ID count can be recorded that reflects messages being sent from a source to the streaming application. After an update and service restart, the count can again be collected to see if data is flowing through the streaming application as expected. Unique database record counts can be reviewed (e.g. after a restart or during ordinary operations) to ensure that no records are being unexpectedly dropped. Data content sampling can also be performed to see that any data transformations are functioning properly. Corrective actions (after a restart or during ordinary operations) can also be taken, including replay of database messages that are dropped, or sending an alert.

Abstract: Provided herein are methods of detecting one or more nucleic acids in a biofluid sample. The methods include adding to the biofluid sample a composition comprising a sufficient amount of dextran sulphate to provide between 50 nM and 5 ?M dextran sulphate when the composition is added to the biofluid sample.

Abstract: Data streaming applications may need to provide high reliability, particularly depending on the nature of the data being streamed. A framework is described that allows a data streaming application to ensure high reliability both during update operations and during ordinary operations. A unique event ID count can be recorded that reflects messages being sent from a source to the streaming application. After an update and service restart, the count can again be collected to see if data is flowing through the streaming application as expected. Unique database record counts can be reviewed (e.g. after a restart or during ordinary operations) to ensure that no records are being unexpectedly dropped. Data content sampling can also be performed to see that any data transformations are functioning properly. Corrective actions (after a restart or during ordinary operations) can also be taken, including replay of database messages that are dropped, or sending an alert.

Abstract: Provided are methods for detecting specific nucleotide sequences in samples. Methods include generating, from the specific nucleotide sequences, nucleic acid constructs containing probe-identification sequences and sample identification sequences, pooling the nucleic acid constructs from the samples into a single combined sample, and determining the abundance of the specific nucleotide sequences in the samples by quantifying the probe-identification sequences and sample-identification sequences of the nucleic acid constructs.

Abstract: Data streaming applications may need to provide high reliability, particularly depending on the nature of the data being streamed. A framework is described that allows a data streaming application to ensure high reliability both during update operations and during ordinary operations. A unique event ID count can be recorded that reflects messages being sent from a source to the streaming application. After an update and service restart, the count can again be collected to see if data is flowing through the streaming application as expected. Unique database record counts can be reviewed (e.g. after a restart or during ordinary operations) to ensure that no records are being unexpectedly dropped. Data content sampling can also be performed to see that any data transformations are functioning properly. Corrective actions (after a restart or during ordinary operations) can also be taken, including replay of database messages that are dropped, or sending an alert.

Abstract: A method and system for building a point-in-time snapshot of an eventually-consistent data store. The data store includes key-value pairs stored on a plurality of storage nodes. In one embodiment, the data store is implemented as an Apache® Cassandra database running in the “cloud.” The data store includes a journaling mechanism that stores journals (i.e., inconsistent snapshots) of the data store on each node at various intervals. In Cassandra, these snapshots are sorted string tables that may be copied to a back-up storage location. A cluster of processing nodes may retrieve and resolve the inconsistent snapshots to generate a point-in-time snapshot of the data store corresponding to a lagging consistency point. In addition, the point-in-time snapshot may be updated as any new inconsistent snapshots are generated by the data store such that the lagging consistency point associated with the updated point-in-time snapshot is more recent.

Abstract: Data streaming applications may need to provide high reliability, particularly depending on the nature of the data being streamed. A framework is described that allows a data streaming application to ensure high reliability both during update operations and during ordinary operations. A unique event ID count can be recorded that reflects messages being sent from a source to the streaming application. After an update and service restart, the count can again be collected to see if data is flowing through the streaming application as expected. Unique database record counts can be reviewed (e.g. after a restart or during ordinary operations) to ensure that no records are being unexpectedly dropped. Data content sampling can also be performed to see that any data transformations are functioning properly. Corrective actions (after a restart or during ordinary operations) can also be taken, including replay of database messages that are dropped, or sending an alert.

Abstract: Data streaming applications may need to provide high reliability, particularly depending on the nature of the data being streamed. A framework is described that allows a data streaming application to ensure high reliability both during update operations and during ordinary operations. A unique event ID count can be recorded that reflects messages being sent from a source to the streaming application. After an update and service restart, the count can again be collected to see if data is flowing through the streaming application as expected. Unique database record counts can be reviewed (e.g. after a restart or during ordinary operations) to ensure that no records are being unexpectedly dropped. Data content sampling can also be performed to see that any data transformations are functioning properly. Corrective actions (after a restart or during ordinary operations) can also be taken, including replay of database messages that are dropped, or sending an alert.

Abstract: A method and system for building a point-in-time snapshot of an eventually-consistent data store. The data store includes key-value pairs stored on a plurality of storage nodes. In one embodiment, the data store is implemented as an Apache® Cassandra database running in the “cloud.” The data store includes a journaling mechanism that stores journals (i.e., inconsistent snapshots) of the data store on each node at various intervals. In Cassandra, these snapshots are sorted string tables that may be copied to a back-up storage location. A cluster of processing nodes may retrieve and resolve the inconsistent snapshots to generate a point-in-time snapshot of the data store corresponding to a lagging consistency point. In addition, the point-in-time snapshot may be updated as any new inconsistent snapshots are generated by the data store such that the lagging consistency point associated with the updated point-in-time snapshot is more recent.

Abstract: A method and system for building a point-in-time snapshot of an eventually-consistent data store. The data store includes key-value pairs stored on a plurality of storage nodes. In one embodiment, the data store is implemented as an Apache® Cassandra database running in the “cloud.” The data store includes a journaling mechanism that stores journals (i.e., inconsistent snapshots) of the data store on each node at various intervals. In Cassandra, these snapshots are sorted string tables that may be copied to a back-up storage location. A cluster of processing nodes may retrieve and resolve the inconsistent snapshots to generate a point-in-time snapshot of the data store corresponding to a lagging consistency point. In addition, the point-in-time snapshot may be updated as any new inconsistent snapshots are generated by the data store such that the lagging consistency point associated with the updated point-in-time snapshot is more recent.

Abstract: A method and system for building a point-in-time snapshot of an eventually-consistent data store. The data store includes key-value pairs stored on a plurality of storage nodes. In one embodiment, the data store is implemented as an Apache® Cassandra database running in the “cloud.” The data store includes a journaling mechanism that stores journals (i.e., inconsistent snapshots) of the data store on each node at various intervals. In Cassandra, these snapshots are sorted string tables that may be copied to a back-up storage location. A cluster of processing nodes may retrieve and resolve the inconsistent snapshots to generate a point-in-time snapshot of the data store corresponding to a lagging consistency point. In addition, the point-in-time snapshot may be updated as any new inconsistent snapshots are generated by the data store such that the lagging consistency point associated with the updated point-in-time snapshot is more recent.

Abstract: Methods, systems, and articles for simultaneously maintaining copies of data in a data center and a cloud computing environment providing network based services. Synchronizing applications monitor modifications to data records made in the data center and the cloud computing environment. The synchronizing applications are also configured to convert modified records from the data center into a format compatible with databases in the cloud computing environment prior to updating the databases in the cloud computing environment, and vice versa.

Abstract: Methods, systems, and articles for simultaneously maintaining copies of data in a data center and a cloud computing environment providing network based services. Synchronizing applications monitor modifications to data records made in the data center and the cloud computing environment. The synchronizing applications are also configured to convert modified records from the data center into a format compatible with databases in the cloud computing environment prior to updating the databases in the cloud computing environment, and vice versa.